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

[Chet Ramey]

On 3/21/17 2:38 PM, Greg Wooledge wrote:
> 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.)

It doesn't, but the text Eric quoted doesn't really apply here anyway,
since it only mentions command substitution.  Arbitrary subshells'
behavior is up to the implementation, and bash does what it does only
to allow the output of jobs to be piped (e.g., `(jobs)' doesn't work
the same way).

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/