Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020809 Description of problem: when bash is invoked as sh (as in a number of scripts), it performs pathname simplifications that break some non-trivial but not unreasonable soft-link patterns. This is a regression from Red Hat Linux 7.3. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.mkdir -p x other/this/dir 2.ln -s ../other/this x/y 3.sh -c 'cd x/y/../this/dir' Actual Results: the cd command fails: sh: line 1: cd: x/y/../this/dir: No such file or directory Expected Results: it should work, just like it does if sh is invoked as bash, or if cd -P is used. Additional info: The problem has nothing to do with CDPATH, or with non-full pathnames as arguments to cd. In fact, I first ran into the problem using full pathnames. strace indicates it simplifies x/y/.. to x before stating x/this, which is wrong, since x/y/.. != x
Changing product.
*** Bug 76049 has been marked as a duplicate of this bug. ***
Chet Ramey says: The behavior described in this report is required by POSIX.2. Read the description of `canonical form' in http://www.opengroup.org/onlinepubs/007904975/utilities/cd.html. Bash does not do this by default; it's part of the bash posix mode. It's documented in the bash info manual: 32. When the `cd' builtin is invoked in LOGICAL mode, and the pathname constructed from `$PWD' and the directory name supplied as an argument does not refer to an existing directory, `cd' will fail instead of falling back to PHYSICAL mode. Since bash goes into posix mode when invoked as `sh', and logical mode is the default, you'll get this behavior whenever bash is invoked as sh, unless you do `set -o physical' somewhere.