Old Macs (which I grew up with) had even more baroque path handling than mentioned in the blog post:
Double colon (::) meant the same as .. on Unix/DOS, that is "go up one level". So you have to be careful when concatenating paths to not get double separators.
Paths starting with : were relative. If a path didn't start with the separator, the first component was the volume name (disk partition). Again, quite unlike Unix.
Also, remember it was common to have spaces in names on Mac, even the default harddrive on Macs was named "Macintosh HD". So an absolute path like "Macintosh HD:Programs:MacWrite" would have been common. (I grew up with Macs in Swedish, so I'm back translating the names here, could be that the names were slightly different in English.)
It took me a long time to understand why colon wasn't a valid character for file names on Mac and I still find the colon separator to be the least visible these days. Finder can display paths with the forward slash separator (defaults write com.apple.finder _FXShowPosixPathInTitle -bool YES), and yet forward slash may be used in a file name created through Finder as noted in the post, while colon cannot (which is not addressed), but creating a file in the terminal named with a colon is possible and the shell will escape it correctly in use. This file then shows up with a slash in place of the colon when viewed in Finder, and conversely the file with a slash in the name shows up in Terminal with a colon!
I'm curious how much of this behaviour is still intentional design vs. just inertia. Are the modern filesystems still constrained by these older choices, or is it mostly for compatibility?
Another Windows oddity: each drive letter has its own current directory. D: doesn't mean the root of D:, it means "wherever you last were on D:". Same with C:foo, which is relative to C:'s current directory. DOS baggage that's still around.
> Another Windows oddity: each drive letter has its own current directory
For NT-based Windows: only in cmd.exe, and other apps which choose to support the same convention. The NT/Win32 API only supports a single per-process directory
There is actually space in NT data structures to store per-drive current directory, but no released version has ever used it. I think they planned to implement the idea in NT itself (or NT’s implementation of Win32), but then settled on just having a single current directory per-process, and faking the old behaviour in cmd.exe using environment variables
By contrast, Windows 1.x/2.x/3.x/9x/Me retained the old DOS behaviour of per-drive current directories, so Win32 does actually have them if you mean the Win32s or 9x/Me implementations of Win32.
Separately, both Linux and macOS support per-thread current directories separate from the per-process current directory, although by default all threads use the process-wide current directory. Last I checked, the macOS implementation was a bit more sophisticated, in that on Linux once the link between process and thread current directory was severed, it was gone for the lifetime of the thread; by contrast, macOS has an API to re-establish it.
Ah, fair. On modern Windows it's really cmd.exe faking it with env vars, not the API. Didn't know NT reserved space for per-drive CWDs and then never used it.
Classic Mac OS aliases are similar to shortcuts on Windows; they are not symbolic links but rather actual files that record the path to the target.
I want to call such aliases "normal" files, as opposed to a link, but the path description is saved in the Resource Fork of the file, not the Data fork.
Resolving an alias can involve network path traversal. You can make an alias of a file on an AFP volume and save it locally, and the next time you use the alias the volume will be auto mounted if necessary. I think you can get similar behavior from other OS configurations.
I seem to recall that if you move or rename a file, the system will update the alias for you. It can't always figure this out. But it will try. That's something you might not see elsewhere...
I've forgotten why AppleScript returns alias objects instead of strings.
12 comments
[ 3.4 ms ] story [ 32.6 ms ] threadDouble colon (::) meant the same as .. on Unix/DOS, that is "go up one level". So you have to be careful when concatenating paths to not get double separators.
Paths starting with : were relative. If a path didn't start with the separator, the first component was the volume name (disk partition). Again, quite unlike Unix.
Also, remember it was common to have spaces in names on Mac, even the default harddrive on Macs was named "Macintosh HD". So an absolute path like "Macintosh HD:Programs:MacWrite" would have been common. (I grew up with Macs in Swedish, so I'm back translating the names here, could be that the names were slightly different in English.)
For NT-based Windows: only in cmd.exe, and other apps which choose to support the same convention. The NT/Win32 API only supports a single per-process directory
There is actually space in NT data structures to store per-drive current directory, but no released version has ever used it. I think they planned to implement the idea in NT itself (or NT’s implementation of Win32), but then settled on just having a single current directory per-process, and faking the old behaviour in cmd.exe using environment variables
By contrast, Windows 1.x/2.x/3.x/9x/Me retained the old DOS behaviour of per-drive current directories, so Win32 does actually have them if you mean the Win32s or 9x/Me implementations of Win32.
Separately, both Linux and macOS support per-thread current directories separate from the per-process current directory, although by default all threads use the process-wide current directory. Last I checked, the macOS implementation was a bit more sophisticated, in that on Linux once the link between process and thread current directory was severed, it was gone for the lifetime of the thread; by contrast, macOS has an API to re-establish it.
Windows handles slash as well, also part of a unification with UNIX style paths intended for XEDOS.
I want to call such aliases "normal" files, as opposed to a link, but the path description is saved in the Resource Fork of the file, not the Data fork.
Resolving an alias can involve network path traversal. You can make an alias of a file on an AFP volume and save it locally, and the next time you use the alias the volume will be auto mounted if necessary. I think you can get similar behavior from other OS configurations.
I seem to recall that if you move or rename a file, the system will update the alias for you. It can't always figure this out. But it will try. That's something you might not see elsewhere...
I've forgotten why AppleScript returns alias objects instead of strings.