Well, by common convention, I suppose. A great many system commands do
offer a '--help' option. In comparison very few system commands have shell
builtins with the same name. Most of the time, whenever anyone types in
`[CMD] --help` interactively, they're looking for the help file from a
binary command. That's why.
"See also: /bin/kill --help" might be a worthwhile addition to the output
of `help kill`, in my opinion.
The '--timeout' option for /bin/kill is particularly useful. Since people
learn how, in part, to use commands from the outputs of `[CMD] --help`,
obfuscating that info seems counterproductive.
Besides, '--help' isn't a listed option for builtin kill (or printf).
$ builtin kill ps; echo $?
bash: kill: ps: arguments must be process or job IDs
1
The string '--help' is obviously neither (process ID nor job ID), but
there's no formal error message. Rather the help file for builtin kill is
printed, when it isn't positively known either way which help message any
user at the CLI might want to see.
In `man bash` the only mention of '--help' is in the OPTIONS section near
the top, where it's intended to refer to `bash --help`. That command/option
combo prints a help file for the bash binary. In the last 10 lines thereof,
there are some pointers about how to get some more information on shell
builtins.
Perhaps (builtin) `kill --help` should print the same output as `bash
--help`? In that case, at least any help file printed from a '--help'
option would consistently refer to the optargs of a binary.
Cheers,
Wiley
On Sun, Aug 10, 2025, 14:58 Lawrence Velázquez <v...@larryv.me> wrote:
> On Sun, Aug 10, 2025, at 5:17 PM, Wiley Young wrote:
> > It seems like using that syntax would indicate an intention to use the
> > binary.
>
> Why would it indicate that? If the unqualified "kill" command
> invokes the built-in, why would you want "kill --help" to show
> help for the *wrong* implementation?
>
> No, the shell does not (and should not) choose implementations
> based on command arguments.
>
> --
> vq
>
