are stdout and stderr different

Discussion in 'C Programming' started by lovecreatesbea...@gmail.com, Jun 29, 2008.

  1. Guest

    For example, in Bourne Shell both stdout and stderr can be re-directed
    to /dev/null,

    $ ./a.out 2>&1 /dev/null

    then is there any difference still?
     
    , Jun 29, 2008
    #1
    1. Advertising

  2. santosh Guest

    wrote:

    > For example, in Bourne Shell both stdout and stderr can be re-directed
    > to /dev/null,
    >
    > $ ./a.out 2>&1 /dev/null
    >
    > then is there any difference still?


    It's customary for stderr to be unbuffered while stdout is usually line
    buffered or fully buffered. These properties can of course be changed
    from within the program by using setvbuf.
     
    santosh, Jun 29, 2008
    #2
    1. Advertising

  3. Guest

    On Jun 29, 1:11 pm, santosh <> wrote:
    > wrote:
    > > For example, in Bourne Shell both stdout and stderr can be re-directed
    > > to /dev/null,

    >
    > > $ ./a.out 2>&1 /dev/null

    >
    > > then is there any difference still?

    >
    > It's customary for stderr to be unbuffered while stdout is usually line
    > buffered or fully buffered. These properties can of course be changed
    > from within the program by using setvbuf.


    Note that the buffer supplied to setvbuf() needs to have a lifetime at
    least as much as the file stream.
    The contents of the buffer are indeterminate. (n1256 - 7.19.5.6 p2)

    stdin is also an input stream, while stdout and stderr are output
    streams.
    That can also be changed from within the program with 'freopen', and
    it's in fact the most common usage of the function.
    'stdin, 'stdout', 'stderr' need not to be modifiable lvalues.
    fclose(stdout); /* so far so good */
    stdout = fopen("helloworld", "w"); /* bad */

    Imagine this case:

    #define stdout __stream(1)
    inline FILE *__stream(size_t i) { return __file; }

    stdout = fopen("helloworld", "w"); /* constraint violation, requires
    diagnostic by the compiler */

    A common mistake is to flush stdin, 'fflush(stdin)' which invokes
    undefined behavior.
    'stdin' doesn't need to be flushed. "flushing" input streams doesn't
    make sense. Typically one wants to read until a newline or EOF is met
    and discard those characters, which could be written as:

    int foo(FILE *stream) { int c; while((c = getc(stream)) != EOF && c !=
    '\n'); return c; }

    The standard doesn't mention what kind of files 'stdin', 'stdout',
    'stderr' are. In fact, the standard does not require these to be valid
    files. (not *file streams* - they do need to be valid file streams)
    It could be that all file operations on these three predefined streams
    failed, however I'm not aware of such implementation.
    The programmer needs not to know what kind of files they are either;
    Just perform the normal checking of the file functions.
    (offtopic: with a standard like POSIX it's also possible to see the
    value of errno for more information on *why* the operation failed, ISO
    C99 defines only three macros, EDOM, EILSEQ, ERANGE which are not
    relevant to file operations. 7.5 p2. Try comp.unix.programmer if you
    are interested to learn about POSIX)
     
    , Jun 29, 2008
    #3
  4. In article <>,
    Malcolm McLean <> wrote:
    >
    >"" <> wrote in message
    >news:
    >> For example, in Bourne Shell both stdout and stderr can be re-directed
    >> to /dev/null,
    >>
    >> $ ./a.out 2>&1 /dev/null
    >>
    >> then is there any difference still?
    >>

    >Not then. Let's say we direct to a file rather than /dev/null. By examining
    >the file, we cannot tell whether a particular line came from stdout or
    >stderr.


    Keep in mind that the above command (when run on a POSIX system, which
    makes this all OT in clc - heh heh - do I get the "first one to say OT
    points" here?) runs the "a.out" command, passing the string "/dev/null"
    as a parameter (argv[1] value in the program) and with stderr pointing
    to the same file descriptor as stdout (presumably, the terminal).

    It doesn't look like anything is being redirected to /dev/null
    (although, of course, the program could do that inside, using, e.g., freopen())
     
    Kenny McCormack, Jun 29, 2008
    #4
    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. Vincent Touquet
    Replies:
    1
    Views:
    592
    Adrian B.
    Sep 3, 2004
  2. Vincent  Touquet
    Replies:
    0
    Views:
    444
    Vincent Touquet
    Sep 6, 2004
  3. ZelluX
    Replies:
    15
    Views:
    821
    Arne Vajhøj
    Jun 25, 2008
  4. ids
    Replies:
    4
    Views:
    1,509
    Keith Thompson
    Apr 14, 2009
  5. Chris Withers
    Replies:
    1
    Views:
    438
    Lie Ryan
    Dec 18, 2009
Loading...

Share This Page