This article is so confused it actually made me wonder if I might have missed some important information about paths all these years, which could have caused that…

If /directory/file points to a file called file in a directory called directory, where does /directory//file point? Is it a file called file in a directory called directory/? Is it a file called /file in a directory called directory?

/ isn’t allowed to be part of a filename.

It turns out this is implementation-specific.

Only the treatment of // at the beginning of the path is implementation specific.

Luckily, most of the time multiple slashes are to be treated as a single slash.

The pathname resolution is covered by POSIX.

/ is a path that points to the root directory, whatever that means.

As explained in the link above it’s the root directory of the current process, which indeed might not be the same for all processes.

Escaping / (and other characters) is usually done with a backslash (\) character.

As mentioned above / isn’t allowed to be a part of a filename. Even if you precede it by \ it is still not part of the filename, but always treated as a path separator. Thus dir\/file refers to a file called file located in a directory called dir\.

What does ‘/.’ mean?

The link above states that “[t]he special filename dot shall refer to the directory specified by its predecessor.” And since / refers to the root directory of the process, so does /.. POSIX doesn’t have a concept of file extensions.

Never mind that not every user need necessarily have a home directory or that the concept of a ‘user’ may not even exist!

The second link refers to the Wikipedia page for unikernels. I don’t see what a unikernel has to do with a critique POSIX concepts like files or users. It doesn’t implement any of them and therefore is irrelevant in a discussion about them.

This means that whenever paths are passed as arguments in a list of arguments that is separated by spaces, spaces need to be escaped.

That’s not an issue with paths themselves, but with how shells treat whitespace. For example there’s no need to escape whitespace when passing paths with C’s execve().

rm won’t let you remove a symlink to a directory if there’s a slash at the end

That is because the trailing slash causes the path to be resolved to the target of the symlink, which is a directory, which rm doesn’t remove unless -r, -R or -d (some implementations) is specified. Compare the output of stat my-symlink-to-a-directory and stat my-symlink-to-a-directory/.

do file extensions even have meaning in unix-like systems at all? i know of graphical file managers using them (sometimes) to set the program to open the file with, but other than that? same with .foo hidden files - the file system doesn’t care (if i understand correctly), only tools like ls et al (but not find for some reason)

u/rbn said it well: its the world surrounding them, not paths itself.

POSIX specifies that : should not appear in paths to be included in PATH: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03

Since <colon> is a separator in this context, directory names that might be used in PATH should not include a <colon> character.

So I doubt most shells will deal correctly with escaped colons in PATH.

Also, if you want an example of a path library designed around supporting many extremely different systems (for better or for worse), check out Common Lisp’s pathnames.

this mixes several issues:

• parsing paths (”/” being root deviates from the other usages of “/”):

  • working with paths only isn’t too complicated imho, the go stdlib packages for this are rather small (see path and filepath).

• environment to parse paths in (spaces as seperators):

  • parsing shell languages is a whole other topic, i guess the oil shell articles frequently linked on lobsters show a good part of that madness.

• file system / os design (symlinks vs. bind mounts):

  • symlinks have their problems

so i guess not paths are madness but the world surrounding them. seems to be a reoccurring theme.

How would you write a path that points to a file called ‘..’ in a directory called dir?

You don’t. The ‘..’ is an implicit hard link and you cannot override it with a link to anything else.

Is there a system that allows directory and file names to overlap?