Bug 48840

Summary: catalina.sh fails to set CATALINA_HOME on newer bash versions
Product: Tomcat 6 Reporter: mdietze <mdietze>
Component: CatalinaAssignee: Tomcat Developers Mailing List <dev>
Severity: major    
Priority: P2    
Version: 6.0.18   
Target Milestone: default   
Hardware: All   
OS: Linux   
Attachments: Suppresses the printing of a path cd'ed to when computing $CATALINA_HOME

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):


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
$ _

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.