On Wed, 21 Jun 2023 15:09:35 +0300, Amir Goldstein wrote: > On Wed, Jun 21, 2023 at 12:24 PM David Disseldorp <ddiss@xxxxxxx> wrote: ... > > > Actually I'm not sure what's this line for. We get $list by "cd $SRC_DIR; echo $1", > > > is there any chance to have "$SRC_DIR" in $t (or $test_dir) ? > > > > Indeed, this line can be dropped. One minor change in behaviour here is > > that a test pattern with a wacky path prefix e.g. ../tests/xfs/00? will > > no longer work. I think breaking such patterns is okay, but it could > > also be resolved by more carefully extracting the last two path > > components. > > > > I didn't want to drop it because I didn't want to change legacy behavior. > When user's cwd is fstests root directory, it may be natural for some > users to use bash auto completion to run the command > ./check tests/generic/001 > > so there may well be users out these that pass test names including > the tests/ prefix and check has always trimmed this prefix. Ah, yes, understood. > There is something a bit confusing about expanding of bash > patterns: > > When the user uses this syntax: > ./check tests/generic/00? > > the shell expands that pattern to a list of 9 arguments passed to > ./check tests/generic/001 tests/generic/002 ... > > But when the user uses the documented syntax: > ./check generic/00? > check gets a single argument and $(cd $SRC_DIR; echo $1) > expands this single argument to a list > > All the above is existing behavior which my patch should > not have changed. The example I gave was "../tests/xfs/00?", which does get broken by this change. It's relative to SRC_DIR and independent of check parameter expansion. As mentioned, I think it's obscure enough usage that this breakage shouldn't be worth bothering about. Cheers, David
