Re: Why is STDERR the default output?

"'Glenn Morse' via unison-users" <[email protected]> writes:

> I'm not seeing anything relevant in the discussion archives, so if I missed something, I apologize!
>
> I was just whipping up a quick script, and has a call to unison in
> it. Running unison always outputs the startup messages ("version,
> Looking for changes, etc."). I didn't really want output from the
> script, and so I added the usual `1>/dev/null` to the end of the
> command, but I discovered that `2>/dev/null​​` is where the output
> stream is written!

A fair question, and I suspect there is no approach that makes everybody
happy.  My quick reactions are:

  The manual should specify this, and if it doesn't, it would be good to
  have a patch (this week, a github PR :-).

  In Unix, programs are often usable as pipes, and read data from stdin
  and write data to stdout.  Errors go to stderr.  Under this scheme,
  the output is placed correctly.  However, it's hard to know what that
  means with a program that controls syncing but doesn't read and write
  files on stdin/stdout.  Overall though, that kind of meta output seems
  properly placed on stderr.

> This seems very odd to me, as I'd expect stdout/stderr to function in
> the same way as everything I've encountered on Linux. Is there a
> reason that normal messaging is going to stderr? Now, I'm not quite
> sure how to capture actual error messages!

Did you compare to scp, rsync, and wget?  The following print meta data
to stderr:
  - wget
  - dd

These are split with errors to stderr and status to stdout:
  - rsync
  - scp

Overall, I lean to both status and errors belonging on stderr, as I see
status as an INFO log message that's basically the error path but not
actually an error, in the spirit of syslog.


You might want -silent or something.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].