1. 15
  1. 16

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

    1. 2

      As it turns out, the concept of paths is not unique to POSIX systems.

      1. 3

        All of these complaints seem to be aimed at specific implementations of that concept, not the idea itself.

        The implementation in question quite clearly being POSIX

        1. 1

          He’s discussing different peculiarities and incompatibilities between different implementations, one of them being POSIX. He mentions many attributes not relevant to POSIX so I would say it’s clear he’s not only discussing POSIX.

    2. 4

      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.

      1. 5

        File extensions don’t really matter. Atleast not under the unix systems I’ve used (including linux)

        Mac does care to some extend I believe but not on a kernel level.

        Having less exceptions in your code makes the code easier to maintain, this is especially true for kernel code.

      2. 3

        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.

        1. 3

          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):

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

          1. 2

            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?

            1. 4

              The author writes:

              Yes, then you need to escape dots: dir/\.\.. Sigh. And there even are multiple ways to do that. dir/\.., for example. Bigger sigh.

              I really wonder where they got the idea for backslash-escaping ., .. and /. That simply doesn’t work.

            2. -4

              TL;DR - Computer science student discovers something that he thought was simple is, in fact, not so simple. Millennial Outrage ensues.

              1. 11

                Software engineer with a masters in computer science, who has fixed bugs in several pathing libraries, talks about how pathing is weird in a lot of facepalming ways, where most other things that we think are “simple but not” are human systems like time and names while this is something programmers created for other programmers and still managed to make it overly complicated. Is written off because he’s a “millennial”.

                1. 4

                  If the author had written his post in the form of “here are some unexpected consequences of the POSIX path standard that might trip you up” instead of coming across as someone who’s never worked with Unix paths before, the reactions might have been more positive.

                  1. 2

                    I would have serious reservations using a path library that was “fixed” in some way by escaping dots with a backslash.

                  2. 3

                    Your ageism is not welcome here.