-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 .. -> /

tuskiomi
  • 127
  • 1
  • @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? – tuskiomi Oct 11 '21 at 20:42
  • Also; in this answer, the user mentions behavior relating to a 'implementation-defined manner'. what sort of behaviors can I expect? https://unix.stackexchange.com/a/12284/459032 – tuskiomi Oct 11 '21 at 20:44
  • /// is a valid path (which is equivalent to /) and cd /// is a valid command. What do you mean by “'cd ///' is not a valid file path”? – Gilles 'SO- stop being evil' Oct 11 '21 at 20:47
  • 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, … – Jörg W Mittag Oct 11 '21 at 20:48
  • @JörgWMittag so it's technical-speak for 'do anything' or 'no wrong answers'? – tuskiomi Oct 11 '21 at 20:53
  • 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. – Jörg W Mittag Oct 11 '21 at 20:56

1 Answers1

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!

  • 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. – tuskiomi Oct 11 '21 at 20:46