Bug 48840 - catalina.sh fails to set CATALINA_HOME on newer bash versions
Summary: catalina.sh fails to set CATALINA_HOME on newer bash versions
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 6.0.18
Hardware: All Linux
: P2 major (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-02 10:33 UTC by mdietze
Modified: 2010-05-24 06:52 UTC (History)
0 users



Attachments
Suppresses the printing of a path cd'ed to when computing $CATALINA_HOME (433 bytes, patch)
2010-03-02 10:33 UTC, mdietze
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description mdietze 2010-03-02 10:33:37 UTC
Created attachment 25079 [details]
Suppresses the printing of a path cd'ed to when computing $CATALINA_HOME

On a newly installed Ubuntu system, this line in catalina.sh fails:

[ -z "$CATALINA_HOME" ] && CATALINA_HOME=`cd "$PRGDIR/.." ; pwd`

After this line, $CATALINA_HOME has a value like this (using '\n' as newline which actually appears in the variable's value):

/path/to/tomcat\n/path/to/tomcat

It seems like when cd'ing the path is printed to stdout, so that $CATALINA_HOME ends up unusable.

This behaviour has been observed with this version of bash:

$ bash --version
GNU bash, Version 4.0.33(1)-release (i486-pc-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
[...]

The problem can be fixed using the attached patch.
Comment 1 mdietze 2010-03-02 11:05:05 UTC
Actually it seems like the behaviour of the 'cd' command as observed on this recent Ubuntu installation is not a bash default but caused by the distro's default settings.

Note how 'cd' echos any path cd'ed to:

$ cd foo/bar
foo/bar
$ _

This is brain-dead but my patch should make catalina.sh bullet-proof against such nonsense.
Comment 2 Konstantin Kolinko 2010-03-02 11:49:15 UTC
Thank you for the patch.

How about setting an explicit value for the CATALINA_HOME variable?
I would say that that is the recommended way to run these scripts.

The POSIX standard [1] defines that there are circumstances when "cd" command should print directory name to stdout. Do you have the CDPATH variable defined?

[1] http://www.opengroup.org/onlinepubs/009695399/utilities/cd.html
Comment 3 mdietze 2010-03-02 13:03:47 UTC
Yes, CDPATH is the culprit. As we all (may) know the bash developers are trying to move towards more POSIX compatibility with every new version. It seems like they've now implemented POSIX-compliant behaviour for the 'cd' command if CDPATH is set. Thus bash behaves correctly (apologies for the 'brain-dead' thing, guys), and scripts need to be cleaned up to deal with this.

Actually I'm not sure what you mean by explicitly setting $CATALINA_HOME. It is already honoured if set, and most people simply do not want to deal with this (e.g. if you're a developer and tend to run several tomcat instances from different directories etc.). 
I'd probably go for the simpler "`dirname $0`/.." stuff as long as the funny-looking relative path in it does not break anything.
Comment 4 Konstantin Kolinko 2010-03-02 13:09:40 UTC
And what your CDPATH value looks like?
Comment 5 mdietze 2010-03-02 13:58:38 UTC
CDPATH on my colleague's system is this: ".:$HOME/src"
Comment 6 Konstantin Kolinko 2010-03-02 15:03:09 UTC
OK, now I see why it happens.
An alternative solution though would be to add
unset CDPATH
to the beginning of catalina.sh
Comment 7 mdietze 2010-03-02 15:08:45 UTC
Hmm, I'd rather make the mechanism more robust. Who knows for which other reasons we may get output from 'cd' on the standard output in the future...
Comment 8 Mark Thomas 2010-03-29 11:55:52 UTC
Thanks for the patch. After some deliberation I went with the original proposal rather than using unset.

The patch has been applied to trunk and proposed for 6.0.x and 5.5.x
Comment 9 Mark Thomas 2010-05-19 12:03:06 UTC
The patch has been applied to 5.5.x and will be included in 5.5.30 onwards.
Comment 10 Mark Thomas 2010-05-19 12:11:29 UTC
This has been fixed in 6.0.x and will be included in 6.0.27 onwards.
Comment 11 Konstantin Kolinko 2010-05-24 06:52:54 UTC
The fix was also applied to tool-wrapper.sh. Will be in 5.5.30, 6.0.27.