what is difference between stdout and stderr ?

Discussion in 'C Programming' started by Cell, Mar 11, 2008.

  1. Cell

    Cell Guest

    when both are connected to screen and the anything written to these
    two constant file pointers will go onto the screen ?
     
    Cell, Mar 11, 2008
    #1
    1. Advertising

  2. 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 ?"

    On 11 Mar, 09:09, Cell <> wrote:

    > 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
     
    Nick Keighley, Mar 11, 2008
    #2
    1. Advertising

  3. Cell

    santosh Guest

    WANG Cong wrote:

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


    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, Mar 11, 2008
    #3
  4. Cell

    santosh Guest

    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.
     
    santosh, Mar 11, 2008
    #4
  5. Cell

    WANG Cong Guest

    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.
     
    WANG Cong, Mar 11, 2008
    #5
  6. Cell

    Doug Miller Guest

    In article <fr5pn6$got$>, santosh <> 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.
    >

    Maybe he works for Microsoft...
     
    Doug Miller, Mar 11, 2008
    #6
  7. Cell

    santosh Guest

    Doug Miller wrote:

    > In article <fr5pn6$got$>, santosh
    > <> 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.
    >>

    > Maybe he works for Microsoft...


    In MS' case of course, the entire program and probably the system too,
    disappears into /dev/null. :)
     
    santosh, Mar 11, 2008
    #7
  8. Cell

    WANG Cong Guest

    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, Mar 11, 2008
    #8
  9. Cell

    WANG Cong Guest

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

    > In article <fr5pn6$got$>, santosh
    > <> 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.
    >>

    > Maybe he works for Microsoft...


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

    Sorry, man.
     
    WANG Cong, Mar 11, 2008
    #9
  10. Cell

    WANG Cong Guest

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

    > Doug Miller wrote:
    >
    >> In article <fr5pn6$got$>, santosh
    >> <> 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.
    >>>

    >> 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. ;-)
     
    WANG Cong, Mar 11, 2008
    #10
  11. Cell

    Guest

    In article <fr5pn6$got$>,
    santosh <> wrote:
    >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
     
    , Mar 12, 2008
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jakk
    Replies:
    4
    Views:
    12,621
  2. Andre
    Replies:
    7
    Views:
    492
    Dan Pop
    Jul 21, 2003
  3. Vincent Touquet
    Replies:
    1
    Views:
    627
    Adrian B.
    Sep 3, 2004
  4. Vincent  Touquet
    Replies:
    0
    Views:
    468
    Vincent Touquet
    Sep 6, 2004
  5. ZelluX
    Replies:
    15
    Views:
    856
    Arne Vajhøj
    Jun 25, 2008
Loading...

Share This Page