Ludovic Courtès writes: > 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.
I'll fix our subversion, but we'll need to keep this option in mind in the future. It doesn't look like it would be *too* tricky ;) >> 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. > :-) My thought was that libtool could get the absolute file name to ls during configure, as it does already with a number of the other tools it uses. I agree that we don't want a "fix" that leaves us with yet more things to patch. -- Eric Bavier Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
