[Top][All Lists]

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

Re: 36-fyi-backname.patch

From: Akim Demaille
Subject: Re: 36-fyi-backname.patch
Date: 25 Oct 2001 12:08:41 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Artificial Intelligence)

>>>>> "Paul" == Paul Eggert <address@hidden> writes:

>> From: Akim Demaille <address@hidden> Date: Wed, 24 Oct 2001
>> 16:31:53 +0200
>> +# $BACKPATH +# &backname ($REL-DIR) +# -------------------- +# If
>> I `cd $REL-DIR', then to come back, I should `cd $BACKPATH'.  +#
>> For instance `src/foo' => `../..'.  +# Works with non strictly
>> increasing paths, i.e., `src/../lib' => `..'.

Paul> Sorry, I don't know what "non strictly increasing" means in this
Paul> context.

Yes, indeed, it's not even increasing at all.  But I think your are
not even referring to this :)

Paul> I guess it goes without saying that $REL-DIR should not be an
Paul> absolute pathname, but shouldn't the comment mention that this
Paul> macro won't work in general if $REL-DIR goes through symbolic
Paul> links?  Nor will it work if at any point in a left-to-right
Paul> traversal of $REL-DIR one encounters more ".."s than ordinary
Paul> filenames.  Finally, unless I'm mistaken, the macro treats //*
Paul> as /, and it removes any trailing /; if so, this should be
Paul> commented too.

This was extracted from Automake, so any of your concern can be the
sign of an actual problem indeed.  I guess we should croak when an
hypothesis is rejected, that would be much safer indeed.  Or try to
improve it.  Fortunately as far as Automake is concerned, only
relative paths are concerned, given that it deals with paths within a
package, so indeed, this has never been exposed before :(


reply via email to

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