Re: Why are parameters to Bash's builtin optional?

[Victor Engmark]

On Fri, Apr 20, 2012 at 9:18 PM, Chet Ramey <chet.ramey@case.edu> wrote:
> On 4/18/12 11:27 AM, Victor Engmark wrote:
>>>  I can see printing a list of builtins, though `enable' already does that.
>>
>> I guess the difference would be that `builtin` prints *all* builtins, and 
>> *never* modifies their state.
>
> What difference does that make?  enable -a prints all builtins, and does
> not modify their state unless told to do so.

Isn't that rather weird semantics? I'd expect `enable -a` to enable
all builtins and print nothing, and `enable -l` to list all builtins,
like the semantics of most *nix tools.

Also, I suppose `builtin`, if it printed builtins, would print *just*
the names of the builtins (unlike enable), so you wouldn't have to
parse the output even a little bit.

> Why not try out something like the following and see what you
> think:
>
> builtin()
> {
>        case $# in
>        0)      enable -a ; return 0 ;;
>        *)      command builtin "$@" ;;
>        esac
> }
>
> That might be enough to make it work for you.

Oh, this wasn't about any non-working script code, but rather to point
out that the behavior of `builtin` is not as expected, and `help
builtin` doesn't mention what it does when no parameters are provided.
I simply propose that the `shell-builtin` argument should be
mandatory, to avoid confusion.

Cheers,
V