> All I know is that some directories look like an "explosion in a
> paint factory" or "angry fruit salad".
I wonder why the die-hard monochrome users keep arguing from a
"but it isn't pretty" point of view. It's not supposed to be pretty,
it's supposed to augment the information presented.
> The
> To me it's the gloriously colorful that keep arguing that other people
> argue "but it isn't pretty".
Care to elaborate?
> Prettiness is the last thing that concerns me, cloaking information with
> gleeful colorized flashlights and blinding me
> IMO, in the presence of -e, "false && false" should terminate
> execution, just as "false && true" should. The entire compound
> statement is false because the first one is.
2013 POSIX says:
The -e setting shall be ignored when executing [...] any command of
an AND-OR list other than the last.
t use of -i is a request for
> interaction, so when the destination path exists, the utility takes
> instructions from whatever responds on standard input.
..which I believe conflicts with what our cp's -i does.
At the bottom of this mail is a patch that drops the ``isatty()''.
Che
On Sat, Mar 05, 2016 at 02:39:41AM +0100, Dmitrij D. Czarkoff wrote:
> > This breaks doing something along the lines of ``yes n | cp -i [...]''
>
> Why would anyone want that?
To simulate what in FreeBSD's and GNU's implementation of cp is the
-n option, i.e. to only copy files that don't already
On Sat, Mar 05, 2016 at 03:03:36AM +0100, Dmitrij D. Czarkoff wrote:
> So the goal of the diff is to replace something like
>
> $ for src in ${files}; do [ -r "$src" ] && cp ${src} dst/; done
>
> with
>
> $ yes n | cp -i ${files} dst/
>
> ?
Or alternatively, to state in the manual that -i w
I've been running the below patch for about a year, which makes
rfcomm_sppd (bluetooth-related) optionally use openpty(3) when the
argument to -t is "auto".
I'm neither sure this is the right way to do it, nor that support for
manually specifying a tty is still needed at all.
Anyway I figured I t
> What is your use case for this?
(It has been a year since I wrote the patch so my memory is a bit foggy.)
I'm using rfcomm_sppd to establish a bluetooth connection to a GPS
receiver, which is then used by gpsd.
Now, the problem was that I couldn't a-priori find an unused /dev/ttyp?
device to be
I can no longer profile programs with gprof on i386, NetBSD 7.99.26.
The test case is a hello world program:
| #include
|
| int
| main(void)
| {
| puts("hello world");
| return 0;
| }
which is compiled using cc -g -pg -o helloworld helloworld.c
Here's what happens:
$ gdb ./hellowor
i.e. GNU grep.
I'm wondering what's the deal with that...? I'm inclined to build
my systems with MKBSDGREP=yes from now on, or is there a good reason
not to?
Timo Buhrmester
> errno is for syscalls.
errno is standard C, there are non-syscall library functions that do,
and are required to, set errno, for example strtol(3) and friends.
$ grep -rlFw errno /usr/share/man/man3 | wc -l
754
(Yes, some/most may set errno due to system calls failing, but
certainly not all of
The "Location"-Header in a HTTP Redirect used to require a full URL,
but as of RFC 7231, relative references are also allowed.
ftp(1) does not understand this; the following patch addresses that issue.
Comments?
diff --git a/usr.bin/ftp/fetch.c b/usr.bin/ftp/fetch.c
index d5b13b6..32f0368 10064
On Fri, May 27, 2016 at 11:58:50AM -0400, Terry Moore wrote:
> Malloc() might fail, and you don't check for that in your new path.
Right, thanks. I meant to use ftp_malloc(), anyway.
> And it's not clear to me how you know that there's a "//" at the strstr()
I believe that the chain of events lea
patch addresses both issues.
Note that NetBSD 6's postconf does not support expansion, so if
backported, the -x must be dropped.
Cheers,
Timo Buhrmester
--- etc/rc.d/postfix.orig 2016-08-18 00:32:51.0 +0200
+++ etc/rc.d/postfix2016-08-18 00:32:41.0 +0200
@@ -44,9
>LOG_POUT - output only the formattted message to stdout
>if pri > LOG_ERR, otherwise stderr
Writing diagnostics to stdout sounds very wrong, I wouldn't want
any program to do that. What for?
> what is stdout actually for then.
I guess the usual distinction is that stdout gets the "proper" output
of a non-sink program (e.g. for ls(1) the actual directory listing,
while diagnostic information (ls: foo: Permission denied) goes
to stderr for the user to look at, and to not have it creep up
> The output isn't designed to be parsed any more than the output of
> /etc/rc.d/samba restart is.
IIRC the output of rc.d scripts is in fact supposed to be parsed by
the postprocessing routines in rc.subr.
> Would you say that both sending these informative messages to stdout is
> a bug?
Due to
Ping?
18 matches
Mail list logo
