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!
Sincerely,
Hengyang
On Tue, Mar 21, 2017 at 10:08 AM Greg Wooledge <wool...@eeg.ccf.org> 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
> example:
>
> 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
> function.
>
> > 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
> hack.
>
> 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
