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 ?

[santosh]

Cell wrote:

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 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.

[Doug Miller]

In article <fr**********@r egistered.motza rella.org>, santosh <sa*********@gm ail.comwrote:

>
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]

Doug Miller wrote:

In article <fr**********@r egistered.motza rella.org>, santosh
<sa*********@gm ail.comwrote:

>>
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...

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

[WANG Cong]

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

In article <fr**********@r egistered.motza rella.org>, santosh
<sa*********@gm ail.comwrote:

>>
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...

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

Sorry, man.

[WANG Cong]

On Tue, 11 Mar 2008 17:45:43 +0530，santosh wrote：

Doug Miller wrote:

>In article <fr**********@r egistered.motza rella.org>, santosh
<sa*********@g mail.comwrote:

>>>
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...

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

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]

In article <fr**********@r egistered.motza rella.org>,
santosh <sa*********@gm ail.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