Re: CVS commit: src/bin/sh

[David Laight <david%l8s.co.uk@localhost>]

On Tue, Jan 05, 2016 at 01:19:36AM +0000, Taylor R Campbell wrote:
>    Date: Mon, 4 Jan 2016 20:06:55 -0500
>    From: christos%zoulas.com@localhost (Christos Zoulas)
> 
>    On Jan 5,  5:33am, kre%munnari.OZ.AU@localhost (Robert Elz) wrote:
>    -- Subject: Re: CVS commit: src/bin/sh
> 
>    |   | Does the exec'ed program know what to do with fd > 2?
>    |   | Is it hard-coded, or do we specify it with -fd N?
>    | 
>    | More likely, if this ever was to be used, it would be /dev/fd/N
>    | but certainly this is not going to be common.
> 
>    Right, otherwise people would complain a lot more about ksh than
>    they currently do looking at the web...
> 
> I'm pretty sure I have shell scripts that rely on /dev/fd/N working as
> an exec'd command argument for N > 2.  An example of an exec'd program
> that uses N > 2 without /dev/fd/N is gpg, with the --passphrase-fd,
> --command-fd, --status-fd options.  I would be unhappy if these broke.
> 
> ...unless I've misunderstood what this thread is about from my very
> cursory skimming of it.

Same here.
I'm pretty sure I've passed /dev/fd/3 as a command line paramter
(although you often want multiple pipes - which is too hard).

I remember some shells closing everything except 0, 1 and 2 on entry
(perhaps unless/if some command line option given).
But that is different.

I'll use 'exec n>file' (etc) to get the shell to access an extra
file (or 2 or more). Although they are probably dup'ed back before
anything is run.

Personally I think it is the job of the scripts to close
any extra fd, not the shell.

	David

-- 
David Laight: david%l8s.co.uk@localhost