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.
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.
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
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.
And what your CDPATH value looks like?
CDPATH on my colleague's system is this: ".:$HOME/src"
OK, now I see why it happens. An alternative solution though would be to add unset CDPATH to the beginning of catalina.sh
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...
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
The patch has been applied to 5.5.x and will be included in 5.5.30 onwards.
This has been fixed in 6.0.x and will be included in 6.0.27 onwards.
The fix was also applied to tool-wrapper.sh. Will be in 5.5.30, 6.0.27.