Re: Bug: different behavior between "jobs -l" and "builtin jobs -l"

[Greg Wooledge]

On Tue, Mar 21, 2017 at 07:32:27PM +0100, Martijn Dekker wrote:
> A workaround for the original poster's problem could be:
> 
>       (unset -f jobs; unalias jobs; eval 'jobs -l') | wc
> 
> The 'eval' is to stop the alias from being expanded at parse time before
> you have a chance to unalias it. This should be about as robust as
> running 'builtin jobs -l', except it still doesn't check whether the
> builtin might have been disabled.

Does this still trigger the "jobs hack"?  Given that the shell is allowed
to use simple lexical analysis to determine whether we're just running
one jobs (or trap) command in the subshell, my first guess would *not* be
that this would work.  (Not least because we are definitely *not* just
running one jobs command; there are at least three commands.)