shell file descriptor programming (was: Unlinked temp files)

[Leslie Mikesell]

In article <11540 at ulysses.homer.nj.att.com> ekrell at hector.UUCP (Eduardo Krell) writes:

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

You mean my 3B2's aren't old enough to have an associated tradition?
Here is a tidbit from the "sysadm" command:
exec 4<&0
echo $* | 3<&0 0<&4 4<&- /bin/su - ${cmd}

Should this sort of thing not work?

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

Why?  It seems non-intuitive and somewhat antisocial in spite of the fact
that it might fix some other program's problems.

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

But it would be more intuitive to continue the previous behaviour
unless explicitly told *not* to.  That is, add a notation to the
shell to set the close-on-exec flag when you want it.  Since there
is already an explicit "close file" notation, it seems almost
unnecessary anyhow.  BTW, how does ksh know how far to go with
its file-closing?  I don't recall seeing a handy way to find the
highest allowable fd other than trying them all until you get an
error.  Is that a reasonable thing to do?

Les Mikesell