Eric Blake wrote: > 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
I'm surprised you leave "." anywhere in your PATH. I don't trust myself not to make typos. With "." in PATH, all it takes is a predictable typo while I'm cd'd to an insecure directory (albeit on a cracked or multi-user system, which is rare), and I'm trojaned. > 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
