34

I mean, all other OSs that I know of use some form of slash as a path separator, so why did Apple choose the colon?

7
  • 4
    Other OS's also provide a command line for typing out path names.
    – Brian H
    Commented Nov 25, 2020 at 20:15
  • 26
    "All other OSes" that I know of include use of dot (quite a few of those), greater-than, and colon as path-name separators. It's mainly Unix derivatives that use "/", and DOS derivatives that use "\" because "/" was already taken.
    – dave
    Commented Nov 25, 2020 at 21:07
  • 18
    Wikipedia has an incomplete list of path formats. A good number don't use / or \. Commented Nov 25, 2020 at 21:13
  • 1
    What a great question! Welcome to RCSE. I'm expecting an interesting mix of historical and technical answers. Commented Nov 26, 2020 at 8:57
  • 6
    When I was a wee lad, I was familiar with CP/M, Vax/VMS and DOS, and at that time CP/M had no folders but had user areas, VMS had proper paths with . separators, and : as prefix delimiters, and DOS was the weirdo with backslashes. At that time, to me, VMS was the most featureful OS, so I'd be probably asking the same question, except why wouldn't paths be separated by periods :) N.B. In contrast with DCL used as the "language" of the VMS command line, the command line in CP/M and DOS felt like a bit of a joke, so it wouldn't enter my mind to treat those as any sort of a "gold standard". Commented Nov 27, 2020 at 6:43

5 Answers 5

44

Colon was inherited from SOS for the Apple III

Unlike one may assume, MacOS (1984/01) did not inherit the colon (:) from Lisa OS (1983/01), which used a hyphen (-) as path separator, but from Apple III's SOS (1980/10), created for the Apple III to manage the huge data pile of a 5 MiB Profile.


Staircase wit:

On colon vs. slash, Apple went not once but twice full circle:

  • SOS had a colon,

  • ProDOS, the direct SOS offspring for the Apple II, switched the colon for a slash (/) when introduced in 1983; its 16-bit follow up

  • ProDOS 16 for the IIgs (as kernel of GS/OS) reintroduced the colon for compatibility with MacOS, which in turn with

  • Mac OSX - (re)introduced the slash to accommodate its Unix base system.

3
  • 3
    And the Finder (or probably, some GUI framework component) complicates matters by still treating : in a file name as a /.
    – chepner
    Commented Nov 27, 2020 at 23:10
  • 2
    @chepner It depends what you mean I guess, but in my mind it's kind of the opposite; Finder allows a / in a file name but "stores" that character as a : in the POSIX view of the filesystem. (Internally it actually seems to store the character as U+F022 at least via its FAT driver.)
    – natevw
    Commented Dec 1, 2020 at 23:54
  • 1
    MacOS was the first Apple OS to use a :. Apple SOS uses / as a path separator. archive.org/details/…
    – Darren
    Commented Apr 25 at 16:36
30

The original Macintosh File System did not support directories. But the Mac did support multiple floppy drives from the start, and colon : was used in fairly standard fashion as a drive prefix analogous to VMS, MS-DOS and elsewhere – Disk:File.

This is only an educated guess, but I suspect they generalized : to a path separator later with HFS as it was already a reserved character for the drive specifier use. This would prevent incompatibility with forward slash / being used as a valid character in existing Mac file names.

2
  • Actually, the original Mac FS did have folders. Each file had a "folder number". The Finder iterated through the singular catalog of the volume, and any file with a matching folder number would be shown in a Finder window. It was extremely inefficient. The real issue was that there was no system call that would accept file paths (no need for it until much later).
    – DrSheldon
    Commented Apr 27 at 0:50
  • @DrSheldon: I suppose you could say early file system supported folders in the same way that later ones support colors. There was a byte in each directory entry that could be set to control the color that should be used be used for a file's icon, but the file system didn't do anything with that byte other than store it.
    – supercat
    Commented Apr 30 at 16:43
30

I think the colon deserves to be considered the original, the one true separator character. All others are mere imitators ;-)

My rationale for this is the seminal paper A General-Purpose File System For Secondary Storage which first laid out the conceptual design of a tree-structured file system. It used ":" to separate components in path names (and in tree names, a distinction we don't generally bother with these days).

Thus, to answer the question - I imagine that the MacOS implementers were simply following historical precedent.

When implemented in Multics, the path separator had become ">", so the honors go to the paper, not the implementation.

George 3 (for the ICL 1900 series) curiously used ":" for a username prefix, but "." for the pathname separator. I suppose this to be similar to the way Unix interprets "~user", except that ":user" was built into the file system.

1
  • 2
    I had to give a +1 even though it is not really answering the question :))
    – Raffzahn
    Commented Nov 25, 2020 at 22:16
20

It's not completely accurate to focus on slashes as the established solution — . was also in the mix, being DEC's choice for both TOPS and VMS.

That said, I'm going to speculate wildly that it comes down to:

  • Apple's Macintosh filing systems were already fairly non-standard — supporting forked files, for example — in support of simplifying the user experience; and
  • : makes a lot more sense to a normal non-computer user than a slash.

E.g. suppose we were important 1980s office people and I told you that I had filed a report under 'Finance: Housing', you'd assume it was in the 'housing' subcategory to 'finance'. If I told you I had filed it as 'Finance/Housing' you'd think it was in the single category that is simultaneously both finance and housing.

So the former better communicates intent.

Couple that with the fact that Macintoshes of the era couldn't even physically read the floppy disks of other machines — other disks were either 5.25" or double density, Macintoshes take 3.5" disks and the pre-SE Macintosh disk controllers can decode single density and GCR only — and there's really no good reason for hewing to slashes.

9
  • 4
    For clarity, TOPS & VMS directories used square brackets and dots. For example, DRIVE1:[DIRA.DIRB.DIRC]SOMEFILE.EXT;32767
    – RonJohn
    Commented Nov 26, 2020 at 4:42
  • 1
    . was also the separator in the BBC Micro's ADFS (which also used $ for the root, ^ for the parent, and @ the current directory).
    – gidds
    Commented Nov 26, 2020 at 9:53
  • 3
    @RonJohn - VMS actually accepted square brackets and angle brackets, the latter for TOPS-20 compatibility. For some time, I used to run with 'SET DEFAULT <>' so as to discover software that foolishly assumed square brackets were the only possibility.
    – dave
    Commented Nov 26, 2020 at 18:03
  • 1
    You only saw them if you asked for them. As far as I recall, RMS had some heuristics so that directory specs in output files use the same sort of brackets that were used for input files. My approach to setting my default dir to use angle brackets made that the case even for current-directory filenames (no directory actually typed).
    – dave
    Commented Nov 26, 2020 at 23:43
  • 2
    @Barmar but not times ...
    – James K
    Commented Nov 28, 2020 at 0:12
2

all other OSs that I know of use some form of slash as a path separator

In addition to multiple DEC OSes, from TOPS-10 to VAX/VMS, using the . as path separator (and putting [directory.and.subdirectory.paths] in square brackets, there was one other widely-used OS that uses dots: Acorn's ADFS from the BBC Micro and later Archimedes range -- the first RISC personal computers, the first ARM computers, and the first 32-bit personal computers. (Also the first GUI with built-in font anti-aliasing as standard, and full-window dragging instead of a dotted outline.)

A typical ADFS file pathname on a hard disc might be:

ADFS::4.$.Documents.Techwriter.Myfile

First the filesystem as RISC OS supports multiple ones. Then the drive/device number. Then $ denoting the root directory, meaning this is an absolute path. Then a folder called Documents and in that a subdirectory called Techwriter and then in that a file called Myfile. No extension as there's a 4-character type embedded in the metadata.

RISC OS is not a historical footnote. It is alive and well, open-source, and runs on multiple modern Arm computers including the Raspberry Pi.

https://www.riscosopen.org/content/

Perhaps the widest impact of RISC OS is that it had the first icon bar, a fixed panel at the bottom of the screen, containing icons for running applications, plus a clock and drive icons.

This inspired NeXT to add the dock to NeXTstep, now found in its modern version, Apple macOS. The NeXTstep dock in turn inspired Microsoft to invent the taskbar in Windows 95.

As for why DOS used it, the OS/2 Museum has explained in depth.

4
  • 1
    Which bit of this answer is the antecedent to MacOS's :? This seems to be the answer to a different question. Commented Apr 25 at 15:35
  • 1
    The earlier DFS (and DNFS) from 1982 also used a . separator — to separate the drive letter from the (single, single-character) directory name as well as to separate that from the filename.  (You could also use . as part of the filename, as long as it wasn't in the first two characters — though IIRC that wasn't common.)
    – gidds
    Commented Apr 25 at 23:35
  • 1
    @TobySpeight I have added a quote to clarify which part of the question I was responding to. Commented Apr 30 at 13:45
  • Other examples: IBM OS/360 and its descendants have file names like SYS1.MACLIB - the SYS1 is not technically a directory, but kind of like one. VM/SP R6 (1988) introduced Shared File System (SFS), which has real directories separated by dots. Tandem/HPE NonStop also uses dots as directory separator. Commented May 3 at 2:12

You must log in to answer this question.

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