are stdout and stderr different

L

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?
 
S

santosh

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

vippstar

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)
 
K

Kenny McCormack

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())
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top