Re: CVS commit: src/bin/sh

[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

| 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