Dear Chet, Thanks for your reply and I apologyze for the mistake I made in the "buggy behavior" section.
I didn't realize that a builtin is forced to run in a subshell until you told me. Yes, as I tried, "jobs" consumes no PID, but even "jobs | true" consumes two. I'll look into the code following the clue you gave me. But back to the user's perspective, as I looked up "help jobs" or "help builtin", the sematics of "builtin" is only for forcing the shell to use the builtin version, right? Actually, I was writing a script that needs to secure the use of the builtin jobs, but now I need to seek for a reliable walkaround instead of using "builtin". So if we don't treat it as a bug, is it still a good suggestion that we write a caveat info the "builtin" help info? Thanks again for your detailed reply! It helps me a lot :-) Sincerely, Hengyang On Tue, Mar 21, 2017 at 8:13 AM Chet Ramey <chet.ra...@case.edu> wrote: > On 3/20/17 7:47 PM, Hengyang Zhao wrote: > > Hello, > > > > I am experiencing an unexpected behavior when using "builtin jobs -l". It > > seems that it's output fd is not as same as "jobs -l" without the builtin > > prefix. So when I piped it into wc, I got different results (as seen in > the > > code I pasted below). > > > > Bash version: GNU bash, version 4.3.43(1)-release > (x86_64-redhat-linux-gnu) > > OS: Fedora 25, kernel 4.9.13-200.fc25.x86_64 > > > > Buggy behavior: > > when we have one or more background processes: > > jobs -l | wc # produces 0 0 0 > > builtin -l | wc # produces non-zero non-zero non-zero > > (This is actually the opposite of what happens, as shown by your examples > below.) > > > I tried to fix the bug, but after I looked at the code, the jobs printing > > procedure clearly prints to stdout. So I think it's not a easy work to > > track down the bug. > > It's not a bug. The first part of a pipeline is always run in a subshell. > That subshell doesn't really have any jobs, since none of the parent's > jobs are children of that shell -- you can't wait for them, for instance. > > There is special-case code that attempts to detect when the `jobs' builtin > is running (execute_cmd.c:execute_subshell_builtin_or_function) and doesn't > remove the jobs from the jobs table in that one case, specifically to allow > the output of `jobs' to be piped. Running the `builtin' builtin defeats > that. > > Chet > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRU c...@case.edu > http://cnswww.cns.cwru.edu/~chet/ > -- Hengyang Zhao Ph.D. Candidate, Electrical Engineering University of California, Riverside
