28

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?

6
  • 3
    Other OS's also provide a command line for typing out path names.
    – Brian H
    Nov 25 '20 at 20:15
  • 20
    "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. Nov 25 '20 at 21:07
  • 13
    Wikipedia has an incomplete list of path formats. A good number don't use / or \. Nov 25 '20 at 21:13
  • 1
    What a great question! Welcome to RCSE. I'm expecting an interesting mix of historical and technical answers. Nov 26 '20 at 8:57
  • 2
    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". Nov 27 '20 at 6:43
37

Colon was inherited from SOS for the Apple III

Unlike one may assume, MacOS (1984/01) did not inherited 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.

2
  • 3
    And the Finder (or probably, some GUI framework component) complicates matters by still treating : in a file name as a /.
    – chepner
    Nov 27 '20 at 23:10
  • 1
    @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
    Dec 1 '20 at 23:54
26

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
  • 1
    I had to give a +1 even though it is not really answering the question :))
    – Raffzahn
    Nov 25 '20 at 22:16
25

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.

14

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
    Nov 26 '20 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
    Nov 26 '20 at 9:53
  • 2
    @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. Nov 26 '20 at 18:03
  • 1
    Regarding usability: Allowing / as a filename character allowed using dates in filenames.
    – Barmar
    Nov 27 '20 at 4:24
  • 2
    @Barmar but not times ...
    – James K
    Nov 28 '20 at 0:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.