2023年2月11日(土) 23:57 岡部将幸 <okab...@hmi.aitech.ac.jp>: > Description: > builtin command "jobs" behaves differntly depending on > the presence or absence of "builtin". > "jobs" outputs to stdout, but "builtin jobs" does not > output to stdout.
This seems to be reproduced in all the Bash versions from 1.14.7 to devel. The problem is related to the condition of whether subshell builtins inherit the job information. In particular, this is related to the following test in the source code [1]: [1] https://git.savannah.gnu.org/cgit/bash.git/tree/execute_cmd.c?h=devel#n5236 $ sleep 1000 & $ : | jobs [1]+ Running sleep 1000 & $ : | command jobs [1]+ Running sleep 1000 & $ echo "$(jobs)" [1]+ Running sleep 1000 & In these cases, the `jobs' builtin inherits the job information of the main shell. $ : | { jobs; } $ (jobs) In these cases, the `jobs' builtin shouldn't print the job information of the main shell. So, the `jobs' builtin in subshells actually inherits the job information only in a limited case, which is implemented in [1]. Now we call the `jobs' builtin through the `builtin' builtin in the reported code, so it bypasses the condition tested in [1]. We can test many other combinations of such indirect builtin calls, where it doesn't inherit the job information if at least one `builtin' is contained in the chain: $ : | command jobs [1]+ Running sleep 1000 & $ : | command command jobs [1]+ Running sleep 1000 & $ : | command command command jobs [1]+ Running sleep 1000 & $ : | builtin jobs $ : | command builtin jobs $ : | builtin builtin jobs $ : | builtin command jobs $ : | builtin builtin builtin jobs -- Koichi
