Bugzilla – Bug 1164895
cd does not switch to the parent directory
Last modified: 2020-02-26 19:12:52 UTC
Contrary to what the documentation says, the command cd does not switch to the parent directory of the current directory. It switches to the directory referred to by a path obtained by stripping the last element of the current directory path (which is not always the path to the current directory). Example: { cd /proc/1/cwd/..; } The parent directory of /proc/1/cwd is / — but the command takes me to /proc/1 instead.
In other words, assuming you are in /proc/1/cwd, the following instructions are not equivalent: * { cd ../mnt; } * { cd .. && cd mnt; }
I doubt that this is a real bug. Two points: (1) "cd" is a shell internal command. So you ought mention which shell you are using. (2) "/proc" isn't a real file system. It is a virtual construct. So what happens in "/proc" is not a good indication of what would happen in a real file system.
(In reply to Neil Rickert from comment #2) > I doubt that this is a real bug. The shell behaves differently than documented, so it is a bug. > > Two points: > > (1) "cd" is a shell internal command. So you ought mention which shell you > are using. > The documentation is about Bash. > (2) "/proc" isn't a real file system. It is a virtual construct. So what > happens in "/proc" is not a good indication of what would happen in a real > file system. Take /var/run for the same effect.
That sounds a bit like splitting hairs to me, because it depends on the definition of current path. Given the command names that exist to show paths I would argue that current path==working directory which differs from the real path: > cd /var/run/ > pwd > /var/run > realpath . /run the result of "cd -P .." is probably the behavior you expect, but IMHO this is not what the majority would expect. I agree with you that the description in our docs is wrong--strictly technically spoken--but it nevertheless describes the expected behavior. Changing/explaining this causes IMHO more confusion than clarity and therefore I would like to leave it as is.
(In reply to Frank Sundermeyer from comment #4) > describes the expected behavior. Changing/explaining this causes IMHO more > confusion than clarity and therefore I would like to leave it as is. I would change it to "the previous directory in the current path", which is correct and not oh so confusing IMHO. It works path-wise, not inode-wise.
I'll note that I normally use "csh" (which is really "tcsh") as my shell. And "csh" has always behaved this way (even before there was a "tcsh"). That is to say "cd .." prunes the last item from $cwd. I consider this a feature, not a bug. The Bourne shell worked the other way. But "bash" includes some of the nice features from "csh", and I guess this is one of them. If I start a subshell with the "csh" command, then "cd .." will work as you expect, because $cwd is not passed to the subshell. However, if I start an internal subshell by using parentheses, as in ( subshell commands ) then $cwd is passed. It's a matter of getting used to your shell features. With csh: cd /var/run pwd returns "/run". But bash fakes that, too. Hmm, if I invoke the shell as "/bin/sh" (instead of as "/bin/bash") it still behaves that way. I suppose that's a "bashism". I don't know whether that adversely affects any shell scripts. If there is a bug, it would seem to me that the bug is that even when invoked as "/bin/bash" it behaves the way you describe.
(In reply to Neil Rickert from comment #6) > If there is a bug, it would seem to me that the bug is that even when > invoked as "/bin/bash" it behaves the way you describe. The bug is in the documentation.