Re: [BUG] ERR trap triggered twice when using 'command'

[Nick Chambers]

On 4/2/18, 10:32 AM, "Martijn Dekker" <martijn@inlv.org> wrote:

    Op 02-04-18 om 15:48 schreef Nick Chambers:
    > While you should still use the bashbug tool,
    
    Sorry, but I can't be bothered.
    
    All my bug reports are against the current git snapshot.

You should still be providing this information :). How else would you expect 
people to help you.
    
    The environment is irrelevant for this issue. The behaviour is the same 
    for every bash version on every OS, down to at least 2.05b (the earliest 
    bash version in my collection of test shells).
    
    > NickChambers-iMac:~ Nick$ type command
    > command is a shell builtin
    > 
    > This means that when you execute `command false`, false is executed
    > in a child subshell and command is executed in the current shell, and
    > both return 1.
    
    It means no such thing.

It means exactly that. That’s what builtins are. False is actually a builtin as 
well, but its irrelevant in this case. It doesn’t matter if the program command 
takes is a builtin or external program, both provide the same behavior.
    
    $ bash -c 'command export foo=bar; echo $foo'
    bar
    
    The assignment performed by the 'export' command would not have survived 
    if 'command' had caused 'export' to be executed in a subshell.

Command bypasses functions, not builtins. Export is a builtin and is being 
executed in the same shell. Neither are executed in a subshell.
    
    See here for info on what 'command' is for:
    http://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html
    
    To somewhat translate that to a bash context:
    
    1. 'command' bypasses shell functions. This is useful if a shell 
    function exists by the name of a builtin or external command, but you 
    want to invoke the command directly. (One use case is "overloading" a 
    command, adding extra functionality to it with a shell function while 
    invoking the original command for the rest.)
    
    2. If alias expansion is active, it is useful for bypassing both aliases 
    and shell functions. Bypassing aliases is not mentioned in the POSIX 
    spec or the bash manual, because it happens automatically due to 
    'command' being the command name (unless 'command' itself is aliased, of 
    course).
    
    3. In POSIX mode, 'command' disables the special properties of special 
    builtins. This affects the persistence of variable assignments preceding 
    the command, and whether the shell will exit if the command encounters 
    an error. (Bash always disables these properties when not in POSIX mode.)
    
    Thus, 'command' amounts to a simple pre-command modifier. It makes no 
    sense that using it should cause the ERR trap to be triggered twice for 
    the same command.
    
    On ksh93, pdksh, mksh, and zsh (including zsh's sh emulation), it causes 
    the ERR trap to be triggered only once.
    
    - M.
    
The fact that command is POSIX is irrelevant. As can be seen here: 
http://git.savannah.gnu.org/cgit/bash.git/tree/builtins/command.def#n141, 
command just calls bash’s execute_command 
(http://git.savannah.gnu.org/cgit/bash.git/tree/execute_cmd.c#n392 ). Both are 
executed in the same shell.