[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62406: “! failing-command” pattern in shell tests is wrong
From: |
Eric Bavier |
Subject: |
bug#62406: “! failing-command” pattern in shell tests is wrong |
Date: |
Thu, 23 Mar 2023 18:53:47 +0000 |
On Thu, 2023-03-23 at 17:00 +0100, Ludovic Courtès wrote:
> In <https://issues.guix.gnu.org/43616> (commit
> d8934360d2453a403b5433e71d09188e4ed23b57), we changed:
>
> if command that should fail; then false; else true; fi
>
> to:
>
> ! command that should fail
>
> I had reservations back then, and now I know why: :-)
>
> --8<---------------cut here---------------start------------->8---
> $ bash -xe -c '! true; true'
> + true
> + true
> $ echo $?
> 0
> $ bash -xe -c '! false; true'
> + false
> + true
> $ echo $?
> 0
> --8<---------------cut here---------------end--------------->8---
>
> Whether or not the command following the exclamation mark succeeds, the
> statement succeeds. Bummer.
I think it's maybe not that the statement succeeds regardless. But that 'set
-e' doesn't consider it a "failure". From "The Set Builtin":
'-e'
Exit immediately if a pipeline (*note Pipelines::)... returns a
non-zero status. The shell does not exit if the command that
fails is ..., or if the command's return status is being
inverted with '!'.
So in each of your examples, execution continues to the second 'true'
statement and the overall exit status is 0. This is not the behavior we want
in our tests.
The purpose of d89343 was to ease visual parsing of the tests. I mentioned
having used the '!' syntax in my own shell tests, but I realize now that I
was not relying on `set -e` like guix is.
I'll consider a few options. Do we have a known issue where this is causing
a test to not to catch a failure?
Thanks for bringing this up,
`~Eric
signature.asc
Description: This is a digitally signed message part