A coworker just pointed out something odd, and I'm curious what the explanation might be.

On the systems I've tried, cd /', 'cd //', and 'cd ///' all have the effect of changing directory to the file system root. However, 'cd /; pwd' and 'cd ///; pwd' return a response of '/', but 'cd //; pwd' returns '//', even though it's the file system root, as in the other cases.

What gives?


2 Answers 2


Some systems have used double-slashes to represent hostnames on a network, e.g.,


and POSIX gives a nod to this usage in the description of cd:

An implementation may further simplify curpath by removing any trailing characters that are not also leading <slash> characters, replacing multiple non-leading consecutive characters with a single <slash>, and replacing three or more leading characters with a single <slash>. If, as a result of this canonicalization, the curpath variable is null, no further steps shall be taken.

For example, Apollo workstations did this (see Why the //, #, etc? in Tim Berners-Lee's FAQ).


There are two possible sources of pwd on my system: pwd the bash builtin, and /usr/bin/pwd, which comes from GNU coreutils. When I issue cd //; pwd (using the shell builtin), it types //. However, when I issue cd //; /usr/bin/pwd (using the external), it types /. The actual working directory in both cases, as evidenced by ls output and such, is always the same (the FS root).

Thus, the answer seems to be that there are two different concepts involved: the shell's idea of its working directory, and the actual process CWD. The builtin pwd queries the former, while /usr/bin/pwd (and any other binary) will only have access to the latter, and it's only the former which knows anything about //. Why the shell's concept of a working directory distinguishes between / and //, and what // is supposed to mean, I have no idea.

EDIT: Some searching comes across this question, which sheds some light. Apparently the weird behavior is standards-compliant, though it is still weird.

  • It seems that semantically, any more than one / in a sequence is effectively parsed as one; cd //////var///tmp and cd /var/tmp have the same practical effect vis-a-vis where you end up on the filesystem.
    – DopeGhoti
    Nov 24, 2015 at 20:53
  • This is the case, it seems, with the exception of exactly two slashes at the beginning of a path, which "may be interpreted in an implementation-defined manner". (SUS, linked here).
    – Tom Hunt
    Nov 24, 2015 at 20:54

Not the answer you're looking for? Browse other questions tagged .