shell file descriptor programming (was: Unlinked temp files)

[Eduardo Krell]

In article <8473 at chinet.chi.il.us> les at chinet.chi.il.us (Leslie Mikesell) writes:

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

That man page says nothing about individual programs.

>>The only standard file descriptors that all programs expect to be
>>opened are 0, 1, and 2.
>
>Is this documented somewhere?

It's tradition. Why do you think stdio only defines stdin, stdout and
stderr?

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

Those files are opened to the shell. The shell has every right to
exec a process with the close-on-exec flags on all file descriptors
other than 0, 1, 2 and any file descriptors indicated in the command line
(as in "program 3<foo 4>bar").

The real problem is that the close-on-exec flag was a late arrival
into Unix and so the default exec() behavior remained not to use
the close-on-exec flag (because there was no such a flag when it
all started). I think this is a mistake. File descriptors are part
of the environment of a process, and like environment variables,
shouldn't be exported by the shell unless it's done explicitly
(by something like the overloading of the "export" builtin I
described).
    
Eduardo Krell                   AT&T Bell Laboratories, Murray Hill, NJ

UUCP: {att,decvax,ucbvax}!ulysses!ekrell  Internet: ekrell at ulysses.att.com