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.
