Branko Čibej <brane_at_wandisco.com> writes:
> On 08.12.2014 13:03, philip_at_apache.org wrote:
>> Author: philip
>> Date: Mon Dec 8 12:03:23 2014
>> New Revision: 1643793
>>
>> URL: http://svn.apache.org/r1643793
>> Log:
>> * autogen.sh: Unset CDPATH.
>>
>> Modified:
>> subversion/trunk/autogen.sh
>>
>> Modified: subversion/trunk/autogen.sh
>> URL: http://svn.apache.org/viewvc/subversion/trunk/autogen.sh?rev=1643793&r1=1643792&r2=1643793&view=diff
>> ==============================================================================
>> --- subversion/trunk/autogen.sh (original)
>> +++ subversion/trunk/autogen.sh Mon Dec 8 12:03:23 2014
>> @@ -23,6 +23,10 @@
>> ### Run this to produce everything needed for configuration. ###
>>
>>
>> +# Some shells can produce output when running 'cd' which interferes
>> +# with the construct 'abs=`cd dir && pwd`'.
>> +(unset CDPATH) >/dev/null 2>&1 && unset CDPATH
>
> I think the proper solution is to ignore cdpath by changing the
> construct to:
>
> abs=`cd ./dir && pwd`
>
> That is, use an absolute or relative path instead of just a directory
> name. Farily typical usage would be:
>
> abs=$(cd $(dirname $0)/foo && pwd)
>
> (or, to avoid bashisms: here=`dirname $0`; abs=`cd "$here/foo" && pwd`)
> which avoids the CDPATH problem entirely, since `dirname $0` will
> resolve to at least ".".
The current way pwd is used:
`cd "$ltpath/../share/libtool/config" && pwd`
is probably immune to the CDPATH problem, in bash/zsh at least, but
CDPATH behaviour is not standardised and so there may be shells that do
something that breaks.
configure and libtool both unset CDPATH as safety measure.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2014-12-08 14:15:57 CET