Re: Examples of concurrent coproc usage?

[Robert Elz]

    Date:        Sat, 13 Apr 2024 16:10:26 -0400
    From:        Chet Ramey <chet.ramey@case.edu>
    Message-ID:  <32bd9e76-24bc-4206-aa8a-8bcc817228b1@case.edu>

  | File descriptors the user saves with exec redirections beyond [0-2]
  | are set to close-on-exec. POSIX makes that behavior unspecified, but
  | bash has always done it.

It is the right way in general, it allows script fragments (like
functions, loaded from external sources) to run external utilities
without passing through file descriptors that they've never heard
of, and so can't explicitly close.

  | Shells don't offer any standard way to modify the state of that flag,

They don't.    But in addition to fdflags our shell (not bash, and it
has no coprocs, or anything similar) interprets the otherwise meaningless

        n>& n

(or n<&n which is essentially the same thing) as a request to turn off
close-on-exec for fd n.   That can be a redirect on a specific command
and applies (like any other redirect) just to that command (that command
will have fd n open after it is exec'd), or it can be applied using "exec"
to the fd in the shell itself (including in a later redirection in the
same exec command which opens fd n originally, if the order of eval of the
necessary bits ends up being defined - gets a bit messy when var expansions
are needed).

Apart from fdflags we don't have a mechanism to turn close-on-exec on
again if it gets disabled that way, that's never seemed necessary.

Perhaps you might have bash interpret it the same way - eventually
perhaps it might become widespread enough to make it into the standard.
And once there is a standard way to turn off close-on-exec maybe any
shells which don't make that the default for fd's > 2 might see the
advantages of doing it, and then perhaps that unspecified in the standard
could go away too (sometime in the future).

kre