The Unix designers came from the GE/MIT Multics project, and Multics inspired some Unix features. In particular, Multics has a hierarchical filesystem, and so does Unix.

On Multics, pathnames were of the form:


but Unix uses


Is there any documentation of why they chose that syntax instead of copying Multics?

I thought of this because > has become common in modern day displays of other hierarchical paths, such as breadcrumb lists in web applications and CSS child selectors.

Multics also used < to represent upward motion in relative pathnames, e.g. Unix


would be


This has a nice symmetry that ../ lacks, although .. has the advantage of being implemented in the filesystem itself (it's simply a link to the parent directory). On Multics, < is implemented in a user-mode library that canonicalizes pathnames before being passed to the kernel.

  • 1
    Somewhat related: retrocomputing.stackexchange.com/questions/4686/…
    – Raffzahn
    Jul 12, 2018 at 19:21
  • 4
    @Raffzahn I saw that, as well as questions about why DOS used backslash instead of slash. The relationship with this question is very tenuous.
    – Barmar
    Jul 12, 2018 at 19:31
  • 14
    As a personal opinion, moderators moving conversations to chat is the worst feature of SE. Jul 14, 2018 at 14:57
  • 2
    @MartinArgerami Comments are not for extended discussion of moderator actions, this discussion should be moved to chat :)
    – Barmar
    Jul 14, 2018 at 15:09
  • 5
    @Barmar: technically I wasn't discussing, but rather stating an opinion. But yes, the restrictive definition of "comment" is equally bad. Some of the best content in SE I've seen in the comments. Jul 14, 2018 at 15:16

3 Answers 3


Primordial Unix on the PDP-7 was in many ways very different from what we know today. Directories existed but were very awkward to use; in practice most work was done in a single directory. Most importantly, paths did not yet exist. What was implemented early on though was a simple syntax for IO redirection on the commandline. Whereas on Multics one would have to say1

iocall attach user_output file xx
iocall attach user_output syn user_i/o

on Unix one could simply say

ls >xx

STDIN could similarly be redirected.

When paths were eventually implemented (on PDP-11 Unix) < and > were already in use so a new syntax was needed. I am unaware of the precise reason / was chosen for this; it's likely that its convenient location on Teletype Model 372 terminals was a consideration.

1 iocall was an 'author-maintained' (i.e. non-standard) command.

2 The Model 37 could easily be adapted to handle mathematical symbols; this was important since early Unix was intended to be used for technical writing (see e.g. roff). The / is next to right-shift on the Model 37, same as on most modern keyboards.

  • I might be misreading but: is the general idea that redirecting input/output in a single operator a really exciting notion/feature for Unix, and that angle brackets were the logical/practical best operator for this, and thus they had to come up with a new token for directory paths?
    – Anthony
    Jul 14, 2018 at 6:27
  • 1
    Or is it more like redirection was this cool thing they implemented with no thought at all for directories/paths (because they were trivial/clunky in other systems) and later when they wanted to adopt them they were like "crap, we've already used > for this other thing, so we need a new token for paths"?
    – Anthony
    Jul 14, 2018 at 6:30
  • 1
    @Anthony That's the impression I've gotten. The PDP-7 system that Unix was created on was very limited in terms of resources. Full paths weren't really needed until the arrival of larger disks (when the PDP-11 was acquired) and the cost (in resources) was a bit high for marginal return. Since directories were inodes from the beginning it made sense to chain a sequence of directories and an optional file (all inodes) together into a path. The choice of / to delimit the sequence was, as I stated above, likely a matter of convenience. Jul 15, 2018 at 18:06
  • 1
    @Anthony Note that on Unix there is no reason to have special syntax for 'parent directory'; a simple ../ will suffice. (The inode listed for the .. entry in the current directory's file/directory list is the parent directory's inode). Unix filesystems were inode-based from the beginning. Jul 15, 2018 at 18:07
  • 1
    +1 to "its convenient location on Teletype Model 37 terminals". Much of early Unix syntax and commands was about keyboard simplification, since apparently the keys on those terminals were pretty stiff.
    – RonJohn
    Jun 8, 2019 at 21:17

There were other hierarchical file systems around.
The Burroughs operating systems used (and as Unisys, still do) / Although in a someone clunky way:

 ^^^^ usercode                    ^^^^^^^ device

MS-DOS and Windows also accept / in file paths, in addition to \. It is the command language where this does not work; system calls are fine.

EMAS-3 used {username:]{groupname.}*localname{_partname} where username is up to 6 letters and digits and the others are up to 11, groups are basically directories except for not being files, and parts have to do with "partitioned data sets" (think ar(1) archives but usefully nested).

  • Wikipedia claims that Multics introduced the hierarchical file system. It was publicized at a conference in 1965. When did Burroughs add it?
    – Barmar
    Apr 25, 2019 at 15:38
  • 3
    Did MS-DOS 2.0 (which added directories) support / out of the box? I have the impression that this was added on later, when Unix had become more popular.
    – Barmar
    Apr 25, 2019 at 15:40
  • 1
    @Barmar Yes, and if you use the SWITCHAR CONFIG.SYS variable to change the default command line switch character from / to something else (eg. -), you could even use / in directory names with the standard MS-DOS commands. This was a feature that only MS-DOS 2.x supported.
    – user722
    Apr 26, 2019 at 17:41
  • Mind you, the reason MS-DOS 2.0 had SWITCHAR was because Microsoft wanted to move the DOS userbase over to XENIX- their variety of Unix. This is the same reason why MS-DOS 2.0 supported a filesystem structure with a similar separator, and a semblance of file permissions. Ironically, these changes were exactly what made people comfortable sticking with a DOS instead of moving to a Unixey.
    – Orion
    Jun 26, 2021 at 19:19

DTSS, developed around the same time as Multics, and influenced by it, used : as the directory separator. A leading : was used for absolute paths (starting at the root directory). There was no easy way to indicate "parent directory" (Unix/Linux ..) — programs that needed to walk the directory tree had to keep track of things themselves.

  • Coincidentally, DTSS was the second OS I used, after TSS/8 on a PDP-8 (this was around 1978). I had a friend in high school whose older brother was a sysadmin for a company that had a DTSS system, and he created a guest account for us to use.
    – Barmar
    Jul 14, 2018 at 3:59
  • 2
    This is interesting, but how does it answer the question? Please read the tour, and then edit your answer.
    – wizzwizz4
    Jul 14, 2018 at 6:42
  • 4
    Classic MacOS also uses a colon, I guess because it makes something close to semantic sense, unlike a slash which in regular English suggests alternatives.
    – Tommy
    Jul 14, 2018 at 17:10
  • So what influence did Dartmouth have on the decision to use / for Unix's path separator? Jul 15, 2018 at 17:20
  • Interestingly, it turns out that ":" was used as the path separator in Multics at an early point in the project's development. See this paper describing the initial development of the multics file system. It looks very much as though Bell Labs may have withdrawn from Multics development at approximately the same time as the path separator was being changed in any case, so it seems that the Unix developers may not have had much chance to become familiar with the Multics syntax described in the question in any case.
    – Jules
    Jul 16, 2018 at 6:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .