Re: Redoing the code in /bin/sh to handle the issues in PR bin/48875

["J. Lewis Muir" <jlmuir%imca-cat.org@localhost>]

On 08/17, Robert Elz wrote:
> I'd appreciate any suggestions for improvements, particularly ways
> to convey the information included in a more succinct form.
> 
> This is the (new) text I currently have ...
> 
>      Note that if a command substitution includes commands to be run in the
>      background, the sub-shell running those commands will only wait for them
>      to complete if an appropriate wait command is included in the command
>      list.  However, the shell in which the result of the command substitution
>      will be used is waiting for both the sub-shell to exit, and for the file
>      descriptor that was initially standard output for the command
>      substitution sub-shell to be closed.

Hi, Robert!

I think this sentence would read better if it used the same verb tense
as the preceding sentence.  In this sentence, I think the verb tense
of "is waiting" is present-continuous, but in the preceding sentence,
I think the verb tense of "will wait" is simple-future.  So, I would
slightly reword this sentence to instead use the simple-future verb
tense (along with removing the comma after "exit") as follows:

  However, the shell in which the result of the command substitution
  will be used will wait for both the sub-shell to exit and for the
  file descriptor that was initially standard output for the command
  substitution sub-shell to be closed.

>                                            While the exit of the sub-shell
>      closes its standard output, any background process left running may still
>      have that file descriptor open.  This includes yet another sub-shell
>      which might have been (almost invisibly) created to wait for some other
>      command to complete, and even where that other command has had its
>      standard output redirected or closed, the waiting sub-shell may still
>      have it open.  Thus there is no guarantee that the result of a command
>      substitution will be available in the shell which is to use it before all
>      of the commands started by the command substitution have completed,
>      though careful coding can often avoid delays beyond the termination of
>      the command substitution sub-shell.

I suggest including an example somewhere in the paragraph since it
won't be read in the context of the PR.  The example could even be the
one from the PR.  When I first read this, I didn't even know a command
inside a "$()" could be terminated with an "&" to cause it to execute in
the background in a sub-shell.  So, an example would help someone like
me understand what this paragraph is talking about.

Lastly, I'm wondering if it would be helpful to include a statement on
best-practice or a good idiom here.  To me, a command substitution that
runs in the background seems weird and like something to avoid.  Is
there really a case where this is useful, or would it be reasonable to
include a suggestion that it's best to avoid such a construct?  Or if
there is a case where this is useful, is this the best way to do it,
and if not, what's a better way to do it?  I'm thinking of something
like the Caveats section of the printf(3) man page where it suggests the
proper secure idiom for avoiding a format string vulnerability.  But
this is not a suggestion I'm confident about; I'm more just wondering
about it.  If it doesn't sound good, then forget it.

Regards,

Lewis