Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!apple!vsi1!wyse!mips!prls!philabs!linus!alliant!merk!spdcc!ima!minya!jc
From: jc@minya.UUCP (John Chambers)
Newsgroups: comp.unix.wizards
Subject: Re: shell file descriptor programming (was: Unlinked temp files)
Message-ID: <134@minya.UUCP>
Date: 12 May 89 16:25:51 GMT
References: <871@marvin.Solbourne.COM> <1015@philmds.UUCP> <296@tree.UUCP> <4542@psuvax1.cs.psu.edu>
Organization: (none)
Lines: 33

In article <4542@psuvax1.cs.psu.edu>, schwartz@shire.cs.psu.edu (Scott Schwartz) writes:
> In article <8087@june.cs.washington.edu>, ka@june (Kenneth Almquist) writes:
> >It's supposed to be a feature.  The idea is that if you save file
> >descriptors by moving them, you don't necessarily want to pass them
> >to the programs you run.
> ...
> >because the feature only applies to file descriptors greater than two.
> 
> Yuck!  What an unpleasant 'feature'.  It's even got magic special cases
> to know about.  Who do I write to to vote against this?

It's definitely a mis-feature, and now I know a good argument against ksh,
at least for some applications.  I've worked on several projects for which
I produced an augmented I/O library that made conventional use of files
3 and higher.  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.  If ksh shoots them down, it'd definitely interfere with such 
an approach.

One of the things that is generally done well on Unix is to set things up
so that they are generic and easily extendible.  This sounds like someone
has decided to take the opposite approach.  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.  This is the opposite of extendibility.  Who
needs such silly restrictions?  

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