shell file descriptor programming (was: Unlinked temp files)

[Leslie Mikesell]

In article <11529 at ulysses.homer.nj.att.com> ekrell at hector.UUCP (Eduardo Krell) 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?

How about the man page for exec(2) where it says that file descriptors
open in the calling process remain open in the new process?

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

Then you should expect an error just like you would get with a program
that wants to open a file that is not accessable.  

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

Is this documented somewhere?  I think the only program that has any
business closing open files if it expects to start general-purpose
children is "getty", and it shouldn't have to.

>You aren't allowed to modify the list because there is no notation
>for it. Someone suggested to overload the export builtin to allow
>to specify which file descriptors would be "exported" to exec'ed
>processes (default being 0, 1, and 2), but the current POSIX draft
>doesn't support that.

If I:
exec 3<foo 4>bar
under what conditions should I not expect to be able to access these
files?

Les Mikesell