On 04/28/2016 07:26 AM, Bishop Bettini wrote: > Hi! > > As described in this Stack Overflow question > <http://unix.stackexchange.com/q/279592/50240>, I'm experiencing what > appears to me as unusual behavior with the jobs command, when jobs is > within a function. In short: > > $ jobs > [1]+ Running vim > [2]+ Stopped matlab > > $ type realjobs > realjobs is a function > realjobs () > { > jobs > } > > $ realjobs | grep vim > $ # no output???
'jobs' is an interesting builtin - the set of jobs in a parent shell is DIFFERENT than the set of jobs in a subshell. Bash normally creates a subshell in order to do a pipeline, and since there are no jobs in that subshell, the hidden execution of jobs has nothing to report. Bash has code to special-case 'jobs |' when it can obviously tell that you are running the jobs builtin as the sole command of the left side of a pipe, to instead report about the jobs of the parent shell, but that special-case code cannot kick in if you hide the execution of jobs, whether by hiding it inside a function as you did, or by other means such as: $ eval jobs | grep vim > $ # funny though, redirection works just fine: > $ tmpfile=$(mktemp); realjobs > $tmpfile; grep vim $tmpfile; rm $tmpfile > [1]+ Running vim Not so funny when you realize that this construct does not create a subshell. > > Commenters on the SO question have also reported unusual results with > combinations on this theme. Am I misunderstanding some behavior of the jobs > built-in or functions? You're misunderstanding that jobs in a subshell are different than jobs in the parent, and the special-casing required to make jobs as the lone element of a subshell behave as if it were jobs in the parent. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
