Re: Cannot grep jobs list when jobs called in a function

[Bishop Bettini]

On Thu, Apr 28, 2016 at 12:38 PM, Eric Blake <eblake@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!