Martijn Dekker <mart...@inlv.org> wrote, on 23 Jul 2020: > > The current POSIX definition (including the current draft) for a subshell > environment is: > > > A subshell environment shall be created as a duplicate of the shell > > environment, except that signal traps that are not being ignored shall > > be set to the default action. Changes made to the subshell environment > > shall not affect the shell environment. > > This does not mention job control. However, I think job control should be > disabled in subshells as it makes no sense to do otherwise, because > subshells are not interactive and you cannot access a subshell job table > from your interactive main shell.
Job control is not a purely interactive feature. You can make (non-interactive) use of job control within a subshell. Of course you can't access those jobs from the parent shell, nor would anyone expect to be able to. > Nearly all shells disable job control for all subshells. Not according to a quick test I just did. The only shell that I tried which won't do job control in a subshell is zsh in its default environment; with "emulate sh" it does. $ for shell in bash dash ksh mksh zsh; do echo $shell ...; $shell -c 'set -m; (sleep 2 & jobs; wait %%)'; done bash ... [1]+ Running sleep 2 & dash ... [1] + Running ksh ... [1] + Running <command unknown> mksh ... [1] + Running \sleep 2 zsh ... zsh:wait:1: can't manipulate jobs in subshell $ zsh -c 'emulate sh; set -m; (sleep 2 & jobs; wait %%)' [2] + running sleep 2 -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
