shell file descriptor programming (was: Unlinked temp files)

[John Chambers]

In article <11529 at ulysses.homer.nj.att.com>, ekrell at hector.UUCP (Eduardo Krell) writes:
> In article <134 at minya.UUCP> jc at minya.UUCP (John Chambers) writes:
> >With /bin/sh, it's easy enough to include in /etc/profile
> >(or wherever) a set of lines that initialize these files to a default (an
> >audit trail, for example), and then just assume that the files are always 
> >available.				  ^^^^^^
> 
> That's the problem. What makes you think this is a safe assumption?
> There are already too many ways of breaking this. Say you want to
> run this program you have from within an editor or a shell script
> or some other program.
> What makes you think the file descriptors you need (>2) are still
> open? Many programs start with closing all file descriptors >2.
> The only standard file descriptors that all programs expect to be
> opened are 0, 1, and 2.

True, but then, it is also easy enough to write code that closes files 
0, 1, and 2, and then does an exec of another unsuspecting program.  
Strictly speaking, no program should ever rely on any files being open,
and even if open, you can't rely on file 0 being readable, etc.  Does
all your code behave correctly in such a case?

This isn't entirely facetious.  There are several Unices around whose
cron starts things up without all the standard files open, and things
started by init are also highly likely to have this problem.

There is a reasonable scenario in which alternative assumptions are
quite reasonable.  Suppose you are building a "turnkey" system that
has Unix inside it, but you supply your own shell to your users, with
a standard setup that only a few wizards even know exists.  Included
would be a set of libraries full of your applications.  It is not at
all unreasonable for programs in these libraries to just assume that
they are being called from the "environment" that you are selling.
The ability to develop such an environment is, after all, one of the
great strengths of Unix.

-- 
John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)

[Any errors in the above are due to failures in the logic of the keyboard,
not in the fingers that did the typing.]