On Jan 5, 5:33am, k...@munnari.oz.au (Robert Elz) wrote:
-- Subject: Re: CVS commit: src/bin/sh
| The exec'd programs in my case however tend to be #!/bin/sh scripts
| that are tightly coupled to the script calling them.
Ok, this I think will break.
| | 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...
| Obviously it would not need to be ! ... N>&&M or N>&:M or something
| that doesn't have a meaning (a sh syntax char would be better than
| a "word" char like : though).
Something like it... Still I think I will start a discussion in the
very infrequently used bourne shell mailing list...
| | I am leaning towards the fcntl builtin solution...
|
| So was I when I finished writing it. Still am.
Heh.
| | Perhaps, if we could do that and re-open with append.
|
| Re-open what? I'm just suggesting a specific (explicit) close in the
| exact same place that a close on exec would happen. What the shell
| does internally if the cmd exec fails we cannot do anything about (or
| rely upon), all that matters is the state left behind after, and in that
| the fd is still open - the close only affects "command".
exec 7>&- 8>&-
command
# reopen 7 and 8 and point them to what they were before.
Now the shell output when it fails to execute command, will not go
to 7 and 8 as it was expected.
| Ah, even though I looked for it, I missed the "to > 2" part. Now I
| just want to see how this gets documented in a way that makes it
| seem other than foolish.
I would say something:
Shell file-descriptor redirections are marked close-on-exec unless the
descriptors they point to refer to the standard input, output, or error.
| Incidentally, the other case, where you call " copyfd(f, fd, 1, fd > 2); "
| the "fd > 2" bit is really redundant, the code inside copyfd (as it exists)
| ends up causing a test that amounts to
|
| if (fd > 2 && fd > 2)
|
| which is kind of redundant. That "fd > 2" might just as well be "1"
| like in the other calls.
Totally redundant.
| I guess I am going to have to set up a current system and try some of
| my scripts that do this kind of thing on it, and see what happens.
| I suspect this kind of sh usage is exotic enough that comparatively few
| people ever use it.
Please do.
| Anyway, enough for now, others probably should be giving opinions
| on how they think all this really should work.
I was waiting for that but I am getting radio silence.
christos
