On 11 Nov 2017, at 23:48, Bill Cole wrote:
On 10 Nov 2017, at 16:03 (-0500), David Ledger wrote:
On 10 Nov 2017, at 4:04, Paul Sture wrote:
On 6 Nov 2017, at 14:54, David Ledger wrote:
[...]
‘/‘ is to be avoided in filenames in Unix systems generally.
Having worked with Unix since (just) before the Mac I’ve never
tried using it with OSX. It may (or may not) work, but it’s a
low-level fiddle-around if it does and could break. Similarly I
avoid ‘:’ as that used to be the pathname separator pre-OSX,
even though it wasn’t as visible to users. There used to be a
compatibility fiddle-around for that, but Apple may have dropped
that by now.
If I remember correctly, ":" is used by AppleScript as the pathname
separator.
Pre-OSX that was generally the case on the Mac, and so filenames with
embedded ‘:’ characters were not allowed. OSX, being Unix based
uses ‘/‘ instead, and added workarounds so that files with either
would sort of work, but they had to be invisibly changed to allow
things to do so.
Not exactly. Current HFS+ & HFSX (still the predominant filesystems
for OSX/macOS) still use ':' on-disk as the path delimiter like all
other descendants of the original HFS. The kernel's "virtual file
system" (VFS) layer swaps ':' and '/' in paths and filenames depending
on context so that POSIX (which is the formal standards family that
defines "Unix-like" OSs) and Cocoa code uses '/' as the path delimiter
while Carbon code uses ':' (if it even uses the concept of a delimiter
at all.) You can create a file named ':' in a shell session but the
Finder will show '/' as its name, as will the low-level HFS+ data
structures on-disk.
There is a Unix system library routine that takes a string of
characters as an argument and returns a pointer to a file on the
basis of that string being a file path. The string has to consist of
sub-strings separated by some delimiter.
Yes, that would be the open() and fopen() system calls, defined in
POSIX as taking a /-delimited path and access mode, returning a file
descriptor. The Cocoa API has direct analogs, the Carbon API does not.
Using the Carbon File Manager, a program can use the filesystem
without any concept of a pathname delimiter.
We’ve wandered off-topic a bit (a lot?) here, but there is no
‘on-disk’ path delimiter. Pathnames are at a higher level. Those
system calls use the underlying library routine I mentioned, which,
IIRC, returns a file reference (inode). I haven’t programmed at this
level for a few years now, but would I hope that Carbon under OSX still
uses the same routines internally, even if it doesn’t expose them to
the programmer. Probably a few bodges in there.
I still avoid ‘/‘ in filenames because I want all my data to be
usable over NFS from Unix systems. And it sound like continuing to avoid
‘:’ is a good idea.
David
_______________________________________________
mailmate mailing list
mailmate@lists.freron.com
https://lists.freron.com/listinfo/mailmate
