joe@hanauma (Joe Dellinger) (05/21/89)
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.
The way it tells whether the output is redirected or not is by
doing
if ( isatty( fileno( stdout ) ) )
{
write into a temp file, then spool it
}
else
{
just write to stdout
}
unfortunately, this doesn't work if the person runs the program in
background as part of a script, logs out, and nobody else happens
to be using the terminal when the program eventually runs. In this
case "isatty" answers "no" for either case.
Questions:
Where is stdout pointing in such a case? Where does stuff written to it go?
How can I tell whether stdout is redirected or not on the command line,
given that "isatty" turns out to not do the job?
We've had strange problems with the permissions on "/dev/tty" randomly
changing to "crw--w--w-", causing many strange errors. I think writing
to stdout and stderr when these are no longer attached to a terminal may
be causing this. Any similar experiences out there? The programs in question
are NOT running with any special privileges, so if they can somehow change
permissions on /dev/tty it is a bug in the OS.
If the answers to any of the above questions are obvious, please only
answer if you roll double sixes on a pair of dice on the first try!
\ /\ /\ /\/\/\/\/\/\/\.-.-.-.-.......___________
\ / \ / \ /Dept of Geophysics, Stanford University \/\/\.-.-....___
\/ \/ \/Joe Dellinger joe@hanauma.stanford.edu apple!hanauma!joe\/\.-._chris@mimsy.UUCP (Chris Torek) (05/22/89)
In article <2421@Portia.Stanford.EDU> joe@hanauma (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. Yuck. 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: real-pspen < plot.data | lpr -Pfoo In particular, the method by which one spools something to a particular printer is *very* system dependent%. For instance, we use MDQS; UCB uses Berkeley lpr; some people use SysV lpr; and once we used a local spooler. All of these are nicely incompatible. ----- % At least, if you will accept degrees of system dependency, spoolers are near the top :-) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
scs@adam.pika.mit.edu (Steve Summit) (05/23/89)
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
scp@raven.lanl.gov (Stephen Pope) (05/23/89)
Well, as long as we're on the subject, I'm curious in general how a process can know whether it is in the foreground or background. We've got a program that does non-blocking reads on all sorts of file handles, including stdin (this is a means for interactive input only; you would not feed it a disk file or the like). It would be very useful to know whether we were in foreground (and should thus look for input from the keyboard) or background (and thus should not expect any). Trying to use isatty() is not an answer - as we'd like the program, in a given instantiation, to be moved from fg to bg and back using the usual job control, and maybe left running after the user logs out the controlling terminal. How is this best done? Stephen Pope Santa Fe Institute scp@sfi.santafe.edu