-1

I noticed in Ubuntu that the following commands go to seemingly different locations in the file system, but the locations have the same files:

cd / cd //

ls-ing from both locations produces the same result:

vm@virtual-machine://$ ls bin dev initrd.img lib64 mnt root snap sys var boot etc initrd.img.old lost+found opt run srv tmp vmlinuz cdrom home lib media proc sbin swapfile usr

Is there a distinction in the behaviors in these to seemingly different, yet the same file paths?

Note: 'cd ///' is not a valid file path, but '//usr/' and '//bin/' are valid paths.
Note-2: So running cd .. in in each points to themselves, so // -> cd .. -> // and / -> cd .. -> /

Improve this question
7
  • 1
    This answers your question: unix, difference between path starting with '/' and '//' Commented Oct 11, 2021 at 20:38
  • @ThomasDickey Sort of! In the answer, the user says "but ///foo is equivalent to /foo", but you can see in my note that /// is not a valid file path. Why is this? is the answer wrong, or are there special cases? Commented Oct 11, 2021 at 20:42
  • Also; in this answer, the user mentions behavior relating to a 'implementation-defined manner'. what sort of behaviors can I expect? unix.stackexchange.com/a/12284/459032 Commented Oct 11, 2021 at 20:44
  • 2
    @tuskiomi: "implementation-defined" is a standard formulation in specifications (it features heavily in C and C++ for example) and means exactly what it sounds like: the behavior is defined by the implementation and the standard does not say anything about what that behavior may be. So, Linux could launch a nuclear missile when you cd // whereas macOS could brick your computer, FreeBSD could do nothing at all, NetBSD could treat it as /, Solaris could use it for file sharing, HP-UX could use it for accessing windows on the desktop, … Commented Oct 11, 2021 at 20:48
  • 1
    @tuskiomi: No, you are thinking of "undefined behavior". "Implementation-defined behavior" is well-defined and predictable, it's just defined in the manual of the implementation rather than the standard. And thus different on different implementations, but consistent on one implementation. Undefined behavior is not required to be consistent even on the same implementation, and in fact, implementations take advantage of that: when a user invokes undefined behavior, the implementation will often assume that behavior to be whatever is fastest. Commented Oct 11, 2021 at 20:56

1 Answer 1

Reset to default
2

According to the POSIX specification, paths that begin with exactly two slashes have implementation-defined semantics.

Multiple slashes in a path are collapsed to one slash, except for the case where there is exactly two slashes at exactly the beginning of the path.

So, /foo, ///foo, ////foo, and ///////////////////foo are guaranteed to be the same path, /foo/bar, /foo//bar, /foo///bar, and so on are guaranteed to be the same path, but /foo and //foo are not guaranteed to be the same path, and neither are //foo and ///foo – any implementation can define the semantics as they wish. They could choose to define //foo to mean the same thing as /foo and ///foo, but they don't have to.

The intention is that operating systems can use paths beginning with // to implement semantics that are different from POSIX file system semantics.

For example, a hypothetical hybrid of Windows and Unix could use // for Windows filesystem semantics. Cygwin actually uses // for network paths, similar to how Windows uses \\.

In Cygwin, for example, cd //; ls would list all SMB fileserver on the local network, not the root directory!

Improve this answer
1
  • Is cygwin the only bash implementation that has special implementation for double-slashes? in my example, I'm using Ubuntu, which doesn't seem to have any special behavior. Commented Oct 11, 2021 at 20:46

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.