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
