Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!mtxinu!unisoft!greywolf
From: greywolf@unisoft.UUCP (The Grey Wolf)
Newsgroups: comp.unix.wizards
Subject: Re: shell file descriptor programming (was: Unlinked temp files)
Message-ID: <2061@unisoft.UUCP>
Date: 22 May 89 21:38:48 GMT
References: <871@marvin.Solbourne.COM> <1015@philmds.UUCP> <296@tree.UUCP> <4542@psuvax1.cs.psu.edu> <134@minya.UUCP> <11529@ulysses.homer.nj.att.com> <8473@chinet.chi.il.us> <11540@ulysses.homer.nj.att.com> <8494@chinet.chi.il.us> <11566@ulysses.homer.nj.att.com>
Reply-To: greywolf@unisoft.UUCP (The Grey Wolf)
Lines: 41

In article <11566@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes:
>In article <8494@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
>
>>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.
>
>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.

Oh, this is just Brilliant.  Does this mean that if I decide to reconfigure
my kernel, I have to recompile my ksh as well?  How many other programs
out there are thus braindead that they become obsolete upon reconfiguration
or tuning of one's kernel?  This is stupid.

There exists something of a system call (in some (good) versions of UNIX)
called getdtablesize(), which returns the size of the Kernel File Table.
I would think that there would be some way of determining the size
of the User File Descriptor Table.  The only way this is currently possible
is by marking your starting point, opening ad nauseum (marking any open
descriptors so they don't get closed later...) and hoping you hit an error,
closing all the descriptors that weren't open and returning the value of
the last valid descriptor.  It's expensive, but it IS accurate.

If you depend upon a header file (like <sys/param.h>), you are getting
the same "approximation of reality" that ps(1) delivers, since you will
have to recompile your program if your local system administrator decides
to re-tune the kernel for different values of NOFILES (or whatever the
constant is these days).

>    
>Eduardo Krell                   AT&T Bell Laboratories, Murray Hill, NJ
>
>UUCP: {att,decvax,ucbvax}!ulysses!ekrell  Internet: ekrell@ulysses.att.com


-- 
"Insane I may be.  I am not stupid."	Antryg Windrose <the mad wizard>