From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Bavier Subject: Re: [PATCH 01/13] gnu: subversion: Propagate env variables to hooks. Date: Tue, 25 Nov 2014 10:51:09 -0600 Message-ID: <87bnnvte9u.fsf@gmail.com> References: <1416548468-28421-1-git-send-email-bavier@member.fsf.org> <1416548468-28421-2-git-send-email-bavier@member.fsf.org> <871towp5ze.fsf@gnu.org> <87ppcgtcoj.fsf@gmail.com> <87k32njy58.fsf@gnu.org> <87r3wriu5w.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtJJM-0008Ux-7z for guix-devel@gnu.org; Tue, 25 Nov 2014 11:50:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XtJJG-0003fQ-QL for guix-devel@gnu.org; Tue, 25 Nov 2014 11:49:56 -0500 In-reply-to: <87r3wriu5w.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: =?utf-8?Q?Ludovic_Court=C3=A8s?= Cc: Guix-devel , Eric Bavier Ludovic Courtès writes: > Eric Bavier 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