are stdout and stderr different

[lovecreatesbea...]

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?

[Malcolm McLean]

"[e-mail]" <lo***************@gmail.comwrote 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.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[santosh]

[e-mail] 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.

[vippstar]

On Jun 29, 1:11 pm, santosh <[e-mail]:

[e-mail] 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[i]; }

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)

[Kenny McCormack]

In article <Pa******************************@bt.com>,
Malcolm McLean <re*******@btinternet.comwrote:

>
"[e-mail]" <lo***************@gmail.comwrote 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())