shell file descriptor programming (was: Unlinked temp files)

[Eduardo Krell]

In article <134 at minya.UUCP> jc at minya.UUCP (John Chambers) writes:

>It's definitely a mis-feature, and now I know a good argument against ksh,
>at least for some applications.

But at the same time, it's a good argument for ksh in some other
applications.  One of the reasons this was put into ksh was the
existance of broken window managers who leave several file descriptors >2
open and cause programs to fail when they run out of file descriptors.

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

>Instead of saying that files
>0,1,2 are open by default, and anyone can extend the list, the approach
>seems to be that exactly files 0,1,2 are open by default, and you aren't
>allowed to modify the list.

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.
    
Eduardo Krell                   AT&T Bell Laboratories, Murray Hill, NJ

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