On 5/27/25 9:15 PM, Shinichiro Kawasaki wrote:
Said that, "set -e" is a good practice in general. If it will help blktests
contributors including you, I would like to revisit this topic.
When I had tried to support "set -e", I faced were two obstacles:
1) There are certain amount of places which trigger sudden exit under "set -e"
condition. To fix this, dirty code changes are required, and this code change
will need rather large amount of effort.
If we would have to make a choice between set -e and code readability
and/or maintainability, I prefer the latter.
2) When a test case exits by "set -e", it may not clean up the test environment.
This may leave unexpected test conditions and affect following test cases.
Now I can think of two solutions respectively.
1) Apply "set -e" practice only for the limited test cases. The new test case
zbd/013 will be the first one. With this approach, we can keep exisiting
scripts as they are, and don't need to spend time to modify them.
Does this mean no "set +e" statements anywhere and hence that statements
that may fail should be surrounded with something that makes bash ignore
their exit status, e.g. if ... then ... fi? In some of my own shell
scripts I define the following function to make it easy to ignore the
exit status of shell commands that may fail:
ignore_failure() {
if "$@"; then :; fi
}
2) Use ERR trap to detect if each test case exited by "set -e". If so, force
stop the "check" script run to avoid influence to following test cases.
As you probably know there should only be one trap ERR or trap EXIT
statement. So that statement should probably occur in the ./check source
instead of in each test script. To make that trap statement perform test
specific cleanup it would have to call a cleanup function defined in the
test/*/* source files.
Another solution is to concatenate all statements that shouldn't fail
with "&&" but that doesn't make the test code look pretty.
Thanks,
Bart.
