On Thu, 2023-03-23 at 17:00 +0100, Ludovic Courtès wrote: > In (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