5 ms·

And who decided it makes sense to list the parent's name first?

rubbingalcohol 7y ago
That makes the hierarchy sortable. Same applies to dates - you can sort 2019-05-24, but not something like 5/24/2019.
kazinator 7y ago
Thompson and Ritchie, who carried it over from Multics to Unix. They worked on Multics, and that OS introduced the hierarchical filesystem. DOS just copied Unix, right down to the | piping, and < > redirection, and . and .. directory links which are fake. Navigation of a path requires that the parents be traversed before children. For instance resolving /usr/bin/ls means we locate the root directory node, then navigate through usr and bin, finally resolving to ls. The components are written in order of traversal, and that order is left to right because English is written left to right. When /usr/bin/ls is passed to the kernel, it's in a character string which is referenced by a pointer to its beginning: it's pointing at the / in /usr. It is natural to process it in that order: visiting the characters in / u s r / b ... order just requires incrementing the pointer byte by byte from the starting value. There are other reasons to have the most major part near the beginning. A telephone number's country code and area code details coming first allows the network to begin make appropriate switching decisions before the dialing is complete. Imagine you had to dial someone's "extension 42" before the company phone number. That extension would have to be stored somewhere, until the company's PBX picks up the call, because that extension only makes sense in the context of that switch. Also, if we collect the absolute path of every object in the file system, and then sort it lexicographically, the parent to child order means that things in the same directories end up nicely listed together.
- trn 7y ago
  See https://en.wikipedia.org/wiki/Path_(computing)#Representations_of_paths_by_operating_system_and_shell https://en.wikipedia.org/wiki/Path_(computing)#Representatio... for a very incomplete list of examples. Also "." was extremely common, used on large DEC systems (RSX, VMS) and Tandem/NonStop as home systems like RISC OS. Multics and VOS use '>' as the separator (and '<' to indicate the parent). The Multics-style paths really are the cleanest, in my opinion. Edit: We run the Public Access Multics system at https://ban.ai/ https://ban.ai/
- chungleong 7y ago
  The computer can easily traverse in either direction. I don't know see any technical reason to list identifiers in that order. No linguistic reason either. We don't do that for addresses in the real world. We don't say "United Kingdom, London, Westminster, Downing Street 10." Imagine if Internet domain names are arranged as file paths. To reach the BBC web site, I'd have to type in "uk.co.bb" before the computer can auto-complete. As it is, all have to do is type the letter B.
  - pacaro 7y ago
    There are real world cultures that use general-to-specific for addresses
    - chungleong 7y ago
      But general tendency is to go from specific to the general. That's because single name is often enough to uniquely identify something in a given context. If I say "10 Downing Street", you'd know that I'm referring to the British PM's office even if we were sitting in Palookaville Kansas. In a filesystem, that's even more true. We aren't going to have dozens upon dozens of files named "xorg.conf". Imagine if file paths were expressed in reverse. You want to edit xorg.conf. As soon as you enter "vi xor" the shell would know enough to auto-complete it to "vi xorg.conf/X11/etc". As it is, organizing files into a logical structure actually makes them harder to find.
      - userbinator 7y ago
        I'd say that's a bit of an edge case. Consider editing a file named README, index.html, .htaccess, or any number of other files which occur in many places with the same name.
        a1369209993 7y ago
        Actually, that could still work: > in<TAB> index.html@. init.sh@.. index.html@foobar@.. ... inputrc@etc@/ The problem I see is this makes it hard to have domain-specific or optional address interpretation. Eg "foo.png=FILE?get@example.com[http]" or... something to that effect.

That makes the hierarchy sortable. Same applies to dates - you can sort 2019-05-24, but not something like 5/24/2019.

Thompson and Ritchie, who carried it over from Multics to Unix. They worked on Multics, and that OS introduced the hierarchical filesystem. DOS just copied Unix, right down to the | piping, and < > redirection, and . and .. directory links which are fake. Navigation of a path requires that the parents be traversed before children. For instance resolving /usr/bin/ls means we locate the root directory node, then navigate through usr and bin, finally resolving to ls. The components are written in order of traversal, and that order is left to right because English is written left to right. When /usr/bin/ls is passed to the kernel, it's in a character string which is referenced by a pointer to its beginning: it's pointing at the / in /usr. It is natural to process it in that order: visiting the characters in / u s r / b ... order just requires incrementing the pointer byte by byte from the starting value. There are other reasons to have the most major part near the beginning. A telephone number's country code and area code details coming first allows the network to begin make appropriate switching decisions before the dialing is complete. Imagine you had to dial someone's "extension 42" before the company phone number. That extension would have to be stored somewhere, until the company's PBX picks up the call, because that extension only makes sense in the context of that switch. Also, if we collect the absolute path of every object in the file system, and then sort it lexicographically, the parent to child order means that things in the same directories end up nicely listed together.

trn 7y ago
See https://en.wikipedia.org/wiki/Path_(computing)#Representations_of_paths_by_operating_system_and_shell https://en.wikipedia.org/wiki/Path_(computing)#Representatio... for a very incomplete list of examples. Also "." was extremely common, used on large DEC systems (RSX, VMS) and Tandem/NonStop as home systems like RISC OS. Multics and VOS use '>' as the separator (and '<' to indicate the parent). The Multics-style paths really are the cleanest, in my opinion. Edit: We run the Public Access Multics system at https://ban.ai/ https://ban.ai/
chungleong 7y ago
The computer can easily traverse in either direction. I don't know see any technical reason to list identifiers in that order. No linguistic reason either. We don't do that for addresses in the real world. We don't say "United Kingdom, London, Westminster, Downing Street 10." Imagine if Internet domain names are arranged as file paths. To reach the BBC web site, I'd have to type in "uk.co.bb" before the computer can auto-complete. As it is, all have to do is type the letter B.
- pacaro 7y ago
  There are real world cultures that use general-to-specific for addresses
  - chungleong 7y ago
    But general tendency is to go from specific to the general. That's because single name is often enough to uniquely identify something in a given context. If I say "10 Downing Street", you'd know that I'm referring to the British PM's office even if we were sitting in Palookaville Kansas. In a filesystem, that's even more true. We aren't going to have dozens upon dozens of files named "xorg.conf". Imagine if file paths were expressed in reverse. You want to edit xorg.conf. As soon as you enter "vi xor" the shell would know enough to auto-complete it to "vi xorg.conf/X11/etc". As it is, organizing files into a logical structure actually makes them harder to find.
    - userbinator 7y ago
      I'd say that's a bit of an edge case. Consider editing a file named README, index.html, .htaccess, or any number of other files which occur in many places with the same name.
      - a1369209993 7y ago
        Actually, that could still work: > in<TAB> index.html@. init.sh@.. index.html@foobar@.. ... inputrc@etc@/ The problem I see is this makes it hard to have domain-specific or optional address interpretation. Eg "foo.png=FILE?get@example.com[http]" or... something to that effect.