Re: CVS commit: src/bin/sh

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 4 Jan 2016 16:50:18 -0500
    From:        christos%zoulas.com@localhost (Christos Zoulas)
    Message-ID:  <20160104215018.4017617FDAD%rebar.astron.com@localhost>


  | Sure, I think that there are examples where the parent/child shells use
  | fds > 2 to communicate, but with an exec'ed program?

Sure, if you're thinking some random NetBSD binary from /bin or /usr/pkg/bin
then probably not.

The exec'd programs in my case however tend to be #!/bin/sh scripts
that are tightly coupled to the script calling them.

  | 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.

  | Well, ! means overwrite in re-directions...

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).

  | I am leaning towards the fcntl builtin solution...

So was I when I finished writing it.  Still am.

  | 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".

  | These two are identical since 0, 1, 2 fd's are never touched.

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.

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.

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.

Anyway, enough for now, others probably should be giving opinions
on how they think all this really should work.

kre