Date: Wed, 04 Jun 1997 09:59:30 -0700
From: Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz>
Subject: Re: Passing file handles to child programs
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: djgpp-workers AT delorie DOT com, Daisuke Aoyama <jack AT st DOT rim DOT or DOT jp>
Reply-to: billc AT blackmagic DOT tait DOT co DOT nz
Message-id: <33959EF2.5D10@blackmagic.tait.co.nz>
Organization: Tait Electronics NZ
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
References: <Pine DOT SUN DOT 3 DOT 91 DOT 970603163701 DOT 314B-100000 AT is>
Precedence: bulk

Eli Zaretskii wrote:
> Solutions?  I can think of two:
> 
>         a) Change low-level libc functions so that they open files with a
> non-inherit bit.  It is a rare program that really needs this on MS-DOS,
> most of the handles beyond the first 5 don't need to be inherited (in
> fact, first thing that COMMAND.COM does when it starts is to close all
> handles from 6 on).  If we NEVER need the inheritance, this is the best
> solution.  However, I'm afraid that Bash relies on the inheritance
> sometimes (to support constructs like "6> foo"), and other programs might
> need this too.  Can anybody comment on this?

This would probably be a good solution so long as any files that NEED to
be 
inherited can. (a flag to open?)

> 
>         b) The second way is a bit kludgy but safer, I think.  We can
> reserve a couple of handles in the first 20 and close them in the code
> that invokes child programs, so that at least a few handles are free on
> the child side.  When the child returns, we just reopen them (say, on NUL
> device).

very hacky and kludgy. I think a would be better so long as the
programmer 
has control.  Yes, this can cause some subtle bugs, but it is rare for
anything
but the first 5 handles to be inherited anyway.

Bill
-- 
Leave others their otherness.