Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: Reading from stderr
Message-ID: <1486@auspex.auspex.com>
Date: 22 Apr 89 20:50:41 GMT
References: <5437@lynx.UUCP> <508@visdc.UUCP> <1094@vsi.COM> <330@hcr.UUCP> <8570@xanth.cs.odu.edu>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Distribution: na
Organization: Auspex Systems, Santa Clara
Lines: 42


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