[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Hengyang Zhao
Subject: Re: Bug: different behavior between "jobs -l" and "builtin jobs -l"
Date: Tue, 21 Mar 2017 17:25:04 +0000

Hi Greg,

Thanks for your explanation! Now it solved my problem. I did misuse the "builtin" builtin when using "jobs". Now I only need to enforce that "jobs" is "enabled", which is not a walkaround :-)

Except one thing that bothers me a tiny bit is that, how about I wrote a "jobs" function and still want to pipe "builtin jobs" somewhere? But I believe I won't make such a use in the near future. Anyways, let me read the code first :-)

Thanks for your time!



On Tue, Mar 21, 2017 at 10:08 AM Greg Wooledge <address@hidden> wrote:
On Tue, Mar 21, 2017 at 04:53:59PM +0000, Hengyang Zhao wrote:
> But back to the user's perspective, as I looked up "help jobs" or "help
> builtin", the sematics of "builtin" is only for forcing the shell to use
> the builtin version, right? Actually, I was writing a script that needs to
> secure the use of the builtin jobs, but now I need to seek for a reliable
> walkaround instead of using "builtin".

A builtin is always used by preference over an external command of the
same name.  You don't need to specify "builtin jobs" to be sure you're
using the builtin.  Just use "jobs".

The only time you need to use the "builtin" command is when you're
defining a function by the same name, and you want bash to use its
builtin instead of your function.  In practice, this should be quite rare.
You'd really only use it if you are creating a wrapper function.  For

cd() {
    local where=${1-$HOME}
    # set xterm title bar
    printf '\e]2;%s\a' "$where"
    builtin cd "$where"

The "builtin cd" at the end prevents bash from recursively calling the

> So if we don't treat it as a bug, is
> it still a good suggestion that we write a caveat info the "builtin" help
> info?

The code that makes bash behave differently when "jobs" is one of the
commands in a pipeline/subshell is kind of a hack.  It's probably not
extremely well known outside of this mailing list, but I suspect many
people have used it without realizing what it is.  It's a fairly intuitive

I've got no strong opinions about whether the "jobs hack" should be
documented.  I don't think the "builtin" command needs any further
explanation, though.  The "help builtin" text already contains a terse
version of the explanation I gave up above.
Hengyang Zhao

Ph.D. Candidate, Electrical Engineering
University of California, Riverside

reply via email to

[Prev in Thread] Current Thread [Next in Thread]