Sebastian Hagedorn wrote: [] > OK. I'm a bit bummed that I still don't get it:
I don't understand it either. Somewhere on the way between the first and the second call of "rem --version" there must be a switch of the PATH variable, but I cannot see any opportunity for doing so, except perhaps inside in the 'setuidgid' program, but even there I don't see how it can happen. > [hgd:coreutils-5.96/tests/rm] hgd% sudo env VERBOSE=yes make check > TESTS=fail-2eperm > Password: > make check-TESTS > + rm --version This is the first call. The 'rm' that answers the call here is the newly compiled one. It is found in the directory "../../src" which has been prepended to PATH by the Makefile. This is good. > rm (GNU coreutils) 5.96 [etc] [] > + fail=0 Everything still OK until here (well, we don't know what is the value of PATH at this point; it is never shown). > ++ setuidgid nobody rm --version The 'setuidgid' executable is found. It sits alongside the newly compiled 'rm' in ../../src. So this directory must still be in PATH, but.. > ++ sed -n '1s/.* //p' > rm: illegal option -- - This is the second call. Now it is a different 'rm' answering here, probably Apple's /bin/rm. So it looks like somehow the directory "/bin" must have been prepended to PATH somewhere between the fist call to 'rm --version' and this point here. But where this is possible I don't know. You could try to place "printenv PATH" at several places into the fail-2eperm script and then run the above make command again. -- Martin ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Fink-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-users
