Hi again,
Another bug: the exit status is not preserved.
Consider
busybox ash -c 'trap "echo ERR" ERR; false; echo $?'
This prints ERR, and then 0, because the echo command completed
successfully. It is supposed to print ERR, and then 1, because like EXIT
actions, ERR actions are supposed to preserve the exit status of the
last command before the action was invoked.
I am also somewhat concerned that there may be cases where the global
variables "doingtrap" and "recursive" are set, but evalstring() exits
via raise_exception() and they are never cleared, preventing future ERR
handlers from running. I do not currently have a test case where it
matters, but am not convinced there are no test cases where it matters.
On 21/08/2021 15:36, Roberto A. Foglietta wrote:
Il giorno sab 21 ago 2021 alle ore 14:38 Harald van Dijk
<[email protected] <mailto:[email protected]>> ha scritto:
Hi,
In bash, the ERR trap is documented as triggering in under the exact
same conditions that 'set -e' would cause the shell to abort. This is
not what you have implemented, you have implemented it as triggering
whenever a simple command returns non-zero. Consider:
trap "echo ERR" ERR
(:) >/access-denied
With bash, this prints:
bash: line 2: /access-denied: Permission denied
ERR
With your patches, this prints:
ash: can't create /access-denied: Permission denied
That is, the ERR action is not executed when it should be. The command
that failed here is not a simple command.
Consider:
trap "echo ERR" ERR
false || true
With bash, this prints nothing. With your patches, this prints ERR.
That
is, the ERR action is executed when it should not be. The command that
failed here is one that had its exit status tested.
The 10th patch reworks the trap ERR in such a way which is compliant
with bash for both these cases.
Thank you,
--
Roberto A. Foglietta
+39.349.33.30.697
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
