[MlMt] Debugging custom keystrokes (another newbie question)

[David Ledger]

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