[MlMt] Debugging custom keystrokes (another newbie question)

[Bill Cole]

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.