On May 29, 2025 / 09:05, Bart Van Assche wrote:
> On 5/28/25 6:08 PM, Shinichiro Kawasaki wrote:
> > On May 28, 2025 / 09:09, Bart Van Assche wrote:
> > > 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?
> >
> > What I'm thinking of is different. What's in my mind is below: (I have not yet
> > implemented, so I'm not yet sure if it is really feasible, though)
> >
> > - If a contributor thinks a new test case should be error free, declare it
> > by adding the "ERREXIT=1" flag at the beginning of the test case.
> > - When "check" script finds the "ERREXIT=1" flag in a test case, it does
> > "set -e" before calling test() or test_device() for the test case. After
> > the call, do "set +e".
> >
> > With this approach, the existing test cases are not affected. And we can do the
> > "set -e" error check in the selected new test cases.
> >
> > Will this approach fit your needs?
>
> Although I'm not enthusiast about the introduction of yet another global
> variable, this would fit my needs.
I see. I thought that the new global variable is required to detect the exit due
to "set -e". But I came up with an idea to not use the new variable. By grepping
"set -e" in the test case script, the "check" script can know if the error exit
may happen in the test case or not.
>
> Does this mean that it is hard to make set -e work in individual tests?
> _check() calls _run_group() in a subshell and _run_group() also calls
> _run_test() in a subshell so the exclamation mark in front of the
> subshell creation shouldn't cause set -e to be ignored, isn't it? The
> use of "time" in _call_test() doesn't affect set -e to be ignored either
> as far as I know.
No. As far as I try on my systems, the restriction by "the exclamation mark in
front of the subshell creation" propagates to subshells. A short script below
shows that the "set -e" in func1() is not working.
#!/bin/bash
func1() {
set -e
ls /foo
echo this should not be printed
set +e
}
if ! ( func1 ); then
echo ""
fi
With this trial, I noticed another important restriction that bash man page
notes: "part of the test following the if or elif reserved words". This also
applies to the blktests test case execution context.
Anyway, these restrictions can be avoided with some tweaks. I have created
trial implementation patches. Will send them out as RFC.
