In article <fr**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:
>WANG Cong wrote:
>And yes, in Linux/Unix, you may want the errors go into a different
direction, e.g. /dev/null, then stdin and stderr differ.
Why would you want to lose all the error messages? They should go to a
log file or to syslog, not /dev/null, IMO.
Because you know what error messages you're expecting, don't want them
to clutter up the output, and don't consider them important enough to
be worth saving to look through afterwards.
(This is obviously not something you want to have happen without
explicitly asking for it. Also, it's extremely rare that error
messages from an interactive program used by a mere mortal should end
up in syslog; if it's something that the people reading the syslog care
about, the system will probably have logged its own error messages
before the error report makes it through the user's program.)
I often find myself saying something like:
grep pattern */* | grep otherpattern
But almost every directory under the current directory has at least one
subdirectory, so grep will whine about not being able to do normal file
I/O on the directory.
Those whines go to stderr, so redirecting stderr to /dev/null will give
me just the output I care about. If that output is broken for some
reason, I can always re-run the grep without redirecting stderr to see
whether the unexpected output is caused by something it's complaining
about.
dave
--
Dave Vandervies dj3vande at eskimo dot com
I was disappointed when I saw the word used in a pre-ANSI draft, and
I am firmly resolved to remain disappointed, no matter the odds.
Harrumph! --Eric Sosman in comp.lang.c