Branko Čibej <br...@wandisco.com> writes: > On 08.12.2014 13:03, phi...@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*
