[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why are parameters to Bash's builtin optional?
From: |
Victor Engmark |
Subject: |
Re: Why are parameters to Bash's builtin optional? |
Date: |
Sat, 21 Apr 2012 11:56:28 +0200 |
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