Reading from stderr

[Guy Harris]

 >In any UNIX variant I have used, I have found that the previous posters
 >were correct in saying that descriptors 0, 1, and 2 are originally created
 >by the sequence

...

 >hence,
 >
 >	read(2, ..., ...);
 >
 >should work.

Note: the word "originally" is very important here.  There is *NO*
guarantee that file descriptor 2 is open for reading!  You might have
done:

	command >file 2>&1		# Bourne/Korn shell

or

	command >&file			# C shell

or piped the standard output and error to another program (e.g.,
"more"), or sent the standard output and error to different files,
or....

Programs should be *VERY* careful about reading from the standard error
- whether doing so directly from file descriptor 2 or doing so from the
standard I/O stream "stderr".  They should *ONLY* do so if they know for
certain that the standard error refers to what they think it does; if
they think it's a synonym for "the user's terminal", they should think
again - it's not guaranteed to refer to the user's terminal.

"/dev/tty" is guaranteed to refer to the process's controlling terminal,
which is generally the user's terminal - assuming the program *has* a
controlling terminal, which it generally won't if run from "cron" or
"at"/"batch", for example - so if they want to be certain they talk to
"the user", they should use "/dev/tty" instead (and be prepared not to
be able to open it; if they can't open it, it's probably because the
program is running as a "cron" or "at"/"batch" job, or being run with
"rsh", or otherwise not being run completely interactively).