Re: File descriptor madness

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Thu, 9 May 2002, Peter Stephenson wrote:

> In this case it's tying up fd 3, right in the paltry set of 9 fd's we
> have available. [...]
> One solution to this problem is to open (or dup something such as fd 0
> onto) all fd's 3 to 9 during initialisation and then close them again
> before any user code is executed

It'd have to be an actual open() or the equivalent, because there's no way
to guarantee that any particular descriptor (even 0) is valid when the
shell starts up.

What's the cheapest/fastest way to create descriptors -- pipe(), perhaps?

On Thu, 9 May 2002, Danek Duvall wrote:

> That said, you may be able to get away with closing the newly opened
> file descriptor afterwards, but I think it would be better to
> artificially force getpwuid() to use a higher fd, or perhaps dup2() to
> move it after the call.

Moving it after the call won't help, as something in the library almost
certainly will still be referring to the old number.

> I'm sure it's been explained before, but why does the limit of 9 fds
> exist?  Is it just because of the limitations in redirection constructs?

It's entirely because of limitations in the redirection syntax.  Really,
there isn't any limit of 10 (0 through 9) -- this works fine if fd 12 is
already open for writing:

	echo twelve >&12

However, only a single digit to the *left* of the redirect operator can be
parsed as an fd number without breaking sh syntax.