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

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.

Note

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