bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: env+nice, one bug fix, two test corrections


From: Eric Blake
Subject: Re: env+nice, one bug fix, two test corrections
Date: Mon, 26 Oct 2009 21:47:51 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]