Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!adam.pika.mit.edu!scs
From: scs@adam.pika.mit.edu (Steve Summit)
Newsgroups: comp.unix.wizards
Subject: Re: What "isatty"?
Message-ID: <11596@bloom-beacon.MIT.EDU>
Date: 22 May 89 22:55:16 GMT
References: <2421@Portia.Stanford.EDU> <17659@mimsy.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 68

In article <2421@Portia.Stanford.EDU> joe@hanauma.stanford.edu (Joe Dellinger) writes:
>	I have a graphics driver program which has 2 basic behaviours.
>If you do
>	pspen < plot.data > file
>it writes postscript code to "file". If you do
>	pspen < plot.data
>it spools the postscript for you.

In article <17659@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>Yuck.

Indeed.

>Programs that produce output should produce the output to stdout.  If
>they will rarely be used to write to anything but the spooler, they
>should be given a less-accessible name and the program the user runs
>should be a shell script:

Another common convention, used by the *roff family, is to use a
-t flag to mean "don't spool; send output to stdout."  (This
could easily be implemented inside of Chris's proposed shell
script.)

In general, if you're trying to print a stream off-line, it's
probably better to pipe your program directly to lpr or the
equivalent, rather than creating your own temp file and
"spooling" that.  That is, do

	prog | lpr -Ppostscript

rather than

	prog > tmpfile
	lpr -Ppostscript tmpfile
	rm tmpfile

Besides removing the opportunity for an unremoved tmp file, the
first approach allows the lpr program to control and optimize tmp
file usage: if it is somehow able to send directly to the device
(although I don't know of such a program) no tmp file need be
required at all.  On the other hand, some lpr programs always
create a temporary copy in a spool directory; by using the first
approach you'll only have generated one temporary copy, not two.

[Joe Dellinger again:]
>Questions:
>Where is stdout pointing in such a case? Where does stuff written to it go?

On some systems, stdout is automatically re-plumbed to /dev/null
when you log out, if it had been connected to a terminal.  (This
is the primary purpose of the infamous vhangup call.)

>How can I tell whether stdout is redirected or not on the command line,
>given that "isatty" turns out to not do the job?

In general, you can't.  Isatty tells you whether or not a file is
a terminal, not whether or not it has been redirected.  If I say

	prog > /dev/tty42

where tty42 is somebody else's terminal, isatty(1) within prog
(if prog runs at all) will return true even though prog's output
has been "redirected."  (prog will not run at all if the system
disallows writes to arbitrary terminals by revoking world write
permission.)

                                            Steve Summit
                                            scs@adam.pika.mit.edu