Re: ‘command … &’ creates subshell

[Eli Schwartz]

On 6/30/20 4:37 PM, Dmitry Alexandrov wrote:
> Chet Ramey <chet.ramey@case.edu> wrote:
>> On 6/29/20 4:33 PM, Dmitry Alexandrov wrote:
>>> 1) unexpected, as (a) it does not seem to be documented, (b) itʼs 
>>> counter-intuitive and (c) other bourne-like shells (busybox ash, dash, 
>>> ksh93, mksh, zsh) does not do that;
>>
>> It's an opportunity for optimization, not a bug
> 
> I am not saying that this is a bug, only that it is inconsistent with almost 
> any other bourne-like shell.

And I understood Chet's point to be that you shouldn't have "expected"
something which isn't guaranteed. Just because it works out that way,
doesn't mean it has to; it's not like other shells document this behavior.

Relying on undocumented behavior isn't the greatest. :p

>>> 2) inconvenient, as in some cases PID of the parent shell is not an 
>>> appropriate substitute for the PID of the real process.
> 
>> since the results are correct.
> 
> The results are _different_ across shell and, unfortunately, results provided 
> by Bash are the least useful.  Consider:
> 
>       $ command … &
>       [1] 30737
>       $ strace -p $!
>       strace: Process 30737 attached
>         wait4(-1,
> 
> :-/

Useful replacements:

You could decline to use "command", and it doesn't involve a shell process.

$ cat &
[1] 2092238
$ ps --pid $! --ppid $!
    PID TTY          TIME CMD
2092238 pts/42   00:00:00 cat

[1]+  Stopped                 cat


If you need to ensure a disk executable is used,

$ "$(type -P cat)" &
[1] 2092352
$ ps --pid $! --ppid $!
    PID TTY          TIME CMD
2092352 pts/42   00:00:00 cat

[1]+  Stopped                 "$(type -P cat)"


Anyway, Chet didn't say it won't be changed to do what you expected;
after all, it's acknowledged as an opportunity for optimization, and
optimization is good..

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

signature.asc
Description: OpenPGP digital signature