Re: nofork command substitution bugs

[Chet Ramey]

On 1/4/24 8:36 AM, Oğuz wrote:
> These bugs affect the development branch only.
>
> 1. `wait -n' doesn't work inside nofork command substitution. I think
> it should, or wait without `-n' shouldn't work either, or what works
> and what doesn't should be documented.

Nofork command substitution freezes the jobs list, because you don't
want jobs appearing and disappearing in the list while you're running
word expansion. If the jobs list is frozen, wait -n doesn't even try
waiting, since you don't want jobs removed from the list in, say, a
SIGCHLD trap. I think it's ok to do the wait but not delete the job,
regardless of what posix says, so I'll make that change for funsubs.

>      $ sleep 3 & sleep 1; echo ${| wait -n -p REPLY;}
>      [1] 433
>
>      $
>      [1]+  Done                    sleep 3
>      $
>
>
> 2. Sending a signal other than SIGTERM to an asynchronous process
> created inside nofork command substitution kills the parent shell.
> This should not happen.

Everything in a command substitution is in the same process group as the
parent shell, since word expansions are performed by the parent shell and
command substitution is a synchronous operation. As a result, asynchronous
processes in nofork command substitutions aren't run in a separate process
group when job control is active. If you send a signal to the process
group, the shell gets it, too. I'm not sure of the right approach here;
I'll have to think about it.


> There are other cases where the parent shell exits unexpectedly, such
> as when the exec command fails inside nofork command substitution, but
> I'm not sure if those are bugs or intended behavior.

Why would that be unexpected, since you're explicitly running something
in the calling shell's context, with the expected side effects to that
environment?


> 3. Linking REPLY to a variable inside nofork command substitution
> renders the target variable unset. I don't think this should be the
> case; and if it has to, it should be documented.

I agree; I don't think the implicit creation of REPLY as a local variable
should follow namerefs here.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

OpenPGP_signature.asc
Description: OpenPGP digital signature