Description of Problem: When CDPATH is set in the users environment cd returns the new path to stdout. As a result, the line in Makefile (generated from automake) that contains: top_distdir=`cd $(distdir) && pwd`; \ produces a problem because the value contains pwd twice, on two lines. User's CDPATH is set by default on rawhide, but not on 7.2. I couldn't find where this is being set. Version-Release number of selected component (if applicable): automake-1.4p5-4 How Reproducible: 100% on rawhide Steps to Reproduce: 1. unpack attached demo package on a rawhide system 2. cd autogenbug-0.1 3. ./autogen.sh 4. ./test.sh Actual Results: ellson@amber:automakebug-0.1> env | grep CDPATH CDPATH=.:/home/ellson:/:/usr/src/redhat ellson@amber:automakebug-0.1> make dist rm -rf automakebug-0.1 mkdir automakebug-0.1 chmod 777 automakebug-0.1 here=`cd . && pwd`; \ top_distdir=`cd automakebug-0.1 && pwd`; \ distdir=`cd automakebug-0.1 && pwd`; \ cd . \ && automake --include-deps --build-dir=$here --srcdir-name=. --output-dir=$top_distdir --gnu Makefile automake: /home/ellson/build/automakebug-0.1/automakebug-0.1.am: `/home/ellson/build/automakebug-0.1/automakebug-0.1.am' does not exist make: *** [distdir] Error 1 Expected Results: Additional Information:
Created attachment 48924 [details] trvial package illustrating problem with "make dist" target
CDPATH is being set in: /etc/profile.d/bashopts.sh This is new in Rawhide.
This bug can be reproduced with automake-1.4p5-2 on 7.2 by setting CDPATH.
Hmm, reproduced, but I claim that "." should not be included in CDPATH. Bero, can't it be taken out?
I agree that the Rawhide default CDPATH looks strange, but changing it isn't a fix for this problem. CDPATH can be set by the user, so automake needs to be made tolerant of any CDPATH setting. Perhaps automake should simply unset it for the duration of the script?
I think the problem with automake only really occurs if "." is in CDPATH. When it isn't, CDPATH being set doesn't cause any trouble for automake, right? Also newer releases of automake (1.5 and 1.6) doesn't seem to be affected CDPATH.
The user can set, and is intended to set, CDPATH to anything they want. This bug is with automake 1.4 which needs to tolerate arbitrary CDPATH settings. automake 1.5/1.6 are irrelevant since they don't work many existing packages (e.g. added depcomps file)
After further testing I realised that bash handles CDPATH differently from zsh. Bash actually needs a "." at the beginning of CDPATH for it to give expected behaviour wrt to cd'ing to a subdir, whereas zsh always tries cwd before searching cdpath. (I guess one can argue about which is the right behaviour, though currently zsh's CDPATH behaviour seems to give less surprise to me.) Further this problem seems to be well-known and also probably affects at least older autoconf and libtool scripts
FYI: Automake 1.6 should correctly ignore the user's CDPATH setting. In fact I believe this constraint is automatically checked by the "maintainer-check" target, to ensure we don't accidentally introduce regressions in this area. Unfortunately this wasn't fixed in the 1.4 series, and we don't plan to make any additional 1.4 releases.
Confirmed that this is fixed with automake-1.6.2.