Bug 61390 - automake needs to tolerate user's CDPATH (even if it shouldn't contain ".")
Summary: automake needs to tolerate user's CDPATH (even if it shouldn't contain ".")
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: automake (Show other bugs)
(Show other bugs)
Version: 1.0
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-03-18 23:09 UTC by ellson
Modified: 2007-04-18 16:41 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-03-25 22:21:57 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
trvial package illustrating problem with "make dist" target (2.01 KB, application/octet-stream)
2002-03-18 23:10 UTC, ellson
no flags Details

Description ellson 2002-03-18 23:09:01 UTC
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:

Comment 1 ellson 2002-03-18 23:10:19 UTC
Created attachment 48924 [details]
trvial package illustrating problem with "make dist" target

Comment 2 ellson 2002-03-18 23:15:14 UTC
CDPATH is being set in: /etc/profile.d/bashopts.sh
This is new in Rawhide.

Comment 3 ellson 2002-03-18 23:32:49 UTC
This bug can be reproduced with automake-1.4p5-2 on 7.2 by
setting CDPATH.

Comment 4 Jens Petersen 2002-03-19 08:50:39 UTC
Hmm, reproduced, but I claim that "." should not be included in CDPATH.
Bero, can't it be taken out?

Comment 5 ellson 2002-03-19 14:10:03 UTC
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?

Comment 6 Jens Petersen 2002-03-20 01:44:05 UTC
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.

Comment 7 ellson 2002-03-20 04:32:18 UTC
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)

Comment 8 Jens Petersen 2002-03-20 13:14:09 UTC
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

Comment 9 Tom Tromey 2002-03-25 22:21:50 UTC
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.


Comment 10 Jens Petersen 2002-07-09 09:06:24 UTC
Confirmed that this is fixed with automake-1.6.2.


Note You need to log in before you can comment on or make changes to this bug.