Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!munnari!murtoa.cs.mu.oz.au!cs.mu.oz.au!kre
From: kre@cs.mu.oz.au (Robert Elz)
Newsgroups: comp.unix.wizards
Subject: Re: shell file descriptor programming (was: Unlinked temp files)
Message-ID: <1508@murtoa.cs.mu.oz.au>
Date: 21 May 89 07:10:38 GMT
References: <871@marvin.Solbourne.COM> <1015@philmds.UUCP> <296@tree.UUCP> <11566@ulysses.homer.nj.att.com>
Sender: news@cs.mu.oz.au
Lines: 21

In article <11566@ulysses.homer.nj.att.com>, ekrell@hector.UUCP (Eduardo Krell) writes:
> The ksh configuration scripts determine how many file descriptors
> your system supports (by running a test program which does dup()'s until
> it fails) and creates a configuration header file which is used to
> compile ksh.

Are you deliberately trying to make us all ill?  The number of file
descriptors is (or should be) a kernel configuration parameter (and
I expect to see config parameters like this turn into boot time options
on many kernels soon).

Now recompiling system dependant stuff like ps when the kernel changes
(though not normally for a minor configuration) is grudgingly acceptable,
but recompiling the shell isn't (I mean, without the shell, how do you
get the new system up to recompile it?)

Not that I really suppose that anything really badly breaks if the shell
is misconfigured this way, but making this kind of information be a
compiled in constant in any program is just asking for trouble.

kre