On Thu, Apr 28, 2016 at 12:38 PM, Eric Blake <ebl...@redhat.com> wrote:
> 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. Ah, gotcha. Thank you for the clarification!
