bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Martijn Dekker
Subject: Re: [BUG] ERR trap triggered twice when using 'command'
Date: Mon, 2 Apr 2018 16:32:00 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

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.

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.

$ 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.

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]