> 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
> 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
Ping?
> 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
> 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
>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?
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
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
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
> 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
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
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
> 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'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
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
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
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
> 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.
18 matches
Mail list logo
