Eric Bavier <ericbav...@gmail.com> skribis: > The culprit, I think, is a small difference in behavior of bash. If PATH > is unset (such as within svn's hook environment), then `bash -c 'echo > $PATH'` on an FHS system prints something like > "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", but Guix's > bash prints "/no-such-path". In the first case, `ls` will resolve to > "/bin/ls", but will not be found in the second.
OK. The /no-such-path comes from the compile-time settings of our Bash, in (gnu packages bash). We could perhaps fix it to refer to Coreutils, but that’s a bit tricky. (Similarly, ‘getconf PATH’ with our libc returns something non-sensical, but I’m not sure what can be done about it.) > Given that behavior, people have nothing to work around. Does Nix's bash > behave differently? No. > I'm not sure that our bash needs to be changed in any way. It's current > behavior seems in line with Guix's way of things. Yes. > I was able to get the tests to pass by simply patching the references to ls > that libtool emits in its wrappers. I think this might be the way to go > for now, Yes, sounds good. > while also submitting a bug to libtool. I don’t think so. Often, the problem is when such scripts contain absolute file names, like /usr/bin/file, which we need to patch. This time they’re “doing it right”, so let’s not suggest the evil thing. :-) Thanks, Ludo’.