Jim Meyering <jim <at> meyering.net> writes: > Looks good, but there was one failure: > > + test xfail = xfail > ++ env sh -c '\c=d echo fail' > sh: c=d: command not found
Aargh. Leaving . on the tail of my PATH is getting the better of me during testing (even though I like the convenience it provides otherwise). Maybe we should modify tests/test-lib.sh to sanitize dot (or more generally, all non- absolute entries) out of PATH? Findutils did something similar, skipping various tests if PATH contains any relative entries. And autotest intentionally rewrites all relative entries in PATH to their absolute counterpart in relation to the directory where the testsuite was started, in order to allow the testsuite can change directory at will without picking up path search effects. At any rate, the fix is just as before, so I'll fold this in (and test without dot in my PATH): - test "x$(env sh -c '\c=d echo fail')" = xpass || fail=1 + test "x$(PATH=$PATH: env sh -c '\c=d echo fail')" = xpass || fail=1 > $ env sh -c '\c=d echo fail' > sh: c=d: command not found Attempts a path search for c=d, with arguments 'echo' and 'fail' if found. > $ env sh -c 'c=d echo fail' Attempts a path search for 'echo' (well, actually a shell builtin search), with environment 'c=d' and argument 'fail'. > test "x$(PATH=$PATH: env sh -c 'exec "$@"' sh c=d echo fail)" = xpass || fail=1 Attempts to do 'exec c=d echo fail', which in turn attempts a path search for program 'c=d' with arguments 'echo' and 'fail'. -- Eric Blake
