what is difference between stdout and stderr ?

[Cell]

when both are connected to screen and the anything written to these
two constant file pointers will go onto the screen ?

 

[Nick Keighley]

please include the topic in the body of your message
(not all news readers display it in an obvious way)

Subject: "what is difference between stdout and stderr ?"

when both are connected to screen and the anything written to these
two constant file pointers will go onto the screen ?

they aren't constant. But yes if you point them both at the same place
then anything directed at either one will go to the same place.
Wouldn't
you be surprised if the behaviour was different?

The point is they can be sent to different places. Eg. in Unix
they can be redirected in the shell. stdout is for output
(eg. in a filter- think of copying one stream to another) and stderr
for errors. You might not want errors to appear in your copied file.
stdout is often (always?) buffered for efficeint i/o whilst
stderr is usually (always?) unbuffered for immediate i/o.
Presumably the assumption is your program will produce
more legitimate output than error messages


--
Nick Keighley

This is not the same as a proof of correctness,
but proofs of correctness can only be constructed by computer
scientists with fancy degrees, not by mere clever programmers.
Ben Pfaff

 

[santosh]

On Tue, 11 Mar 2008 02:59:24 -0700?Nick Keighley wrote?

{snip}


I'd say stdout is default to be line-buffered and stderr is default to
be unbuffered. But, of course, your can use setvbuf to change this.

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.

 

[santosh]

when both are connected to screen and the anything written to these
two constant file pointers will go onto the screen ?

For a standard C program, stdout and stderr both expand to expressions
of type FILE *. They need not be modifiable lvalues, unlike a FILE *
object. They are set, at program start-up to point to the standard
output stream and the standard error stream respectively. To exactly
where these streams connect the standard refrains from specifying, but
on the majority of systems they will connect to the system's output
device, the screen. Typically stdout is line buffered or has full
buffering while stderr is unbuffered, but this can be changed with
setvbuf. You can also use freopen to reorient stdin, stdout and stderr
to point to other named files.

 

[WANG Cong]

On Tue, 11 Mar 2008 02:59:24 -0700，Nick Keighley wrote：

{snip}

they aren't constant. But yes if you point them both at the same place
then anything directed at either one will go to the same place. Wouldn't
you be surprised if the behaviour was different?

The point is they can be sent to different places. Eg. in Unix they can
be redirected in the shell. stdout is for output (eg. in a filter- think
of copying one stream to another) and stderr for errors. You might not
want errors to appear in your copied file. stdout is often (always?)
buffered for efficeint i/o whilst stderr is usually (always?) unbuffered
for immediate i/o. Presumably the assumption is your program will
produce more legitimate output than error messages

I'd say stdout is default to be line-buffered and stderr is default to
be unbuffered. But, of course, your can use setvbuf to change this.

And yes, in Linux/Unix, you may want the errors go into a different
direction, e.g. /dev/null, then stdin and stderr differ.

 

[Doug Miller]

Why would you want to lose all the error messages? They should go to a
log file or to syslog, not /dev/null, IMO.

Maybe he works for Microsoft...

 

[santosh]

Maybe he works for Microsoft...

In MS' case of course, the entire program and probably the system too,
disappears into /dev/null.

 

[WANG Cong]

On Tue, 11 Mar 2008 16:46:52 +0530，santosh wrote：

{snip}

Why would you want to lose all the error messages? They should go to a
log file or to syslog, not /dev/null, IMO.

That's because the errors are what I expected and I don't need them.
I know this is a special case.

 

[WANG Cong]

On Tue, 11 Mar 2008 12:09:36 +0000，Doug Miller wrote：

Maybe he works for Microsoft...

Unfortunately, I am a student and work for Linux kernel.

Sorry, man.

 

[WANG Cong]

Maybe he works for Microsoft...

In MS' case of course, the entire program and probably the system too,
disappears into /dev/null. [/QUOTE]

How do you think this special case of mine?

echo -e '#define cat(c,d) c##.d \n #define mb(a,b) a##@b \n mb(cat
(xiyou,wangcong),cat(gmail,com))' \
| gcc -E -xc - 2>/dev/null |tail -n 1

(I already said it's special. ;-)

 

[dj3vande]

WANG Cong wrote:

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