I have text files which are read by my script. The paths are in Posix and the names of the files have “//” in them. I use “Posix file” to convert the paths to HFS but that process converts the “//” to a colon “:” as in this example:
-- Get path of text file to be read by AppleScript
set path_name to "/Users/Dummy/Desktop/An_example_file_//_to_make_hfs.txt"
set hfs_path_name to POSIX file path_name
The code which opens the file for read fails because the file name is incorrect.
The only way I can see to fix this is to replace all occurrences of “//” with a unique combination before the “posix file” call then replace the unique combination back to “//” after. But, that seems like overkill.
Is there a better way to retain the “//” characters in a HFS file name ?
Ideally, of course, you’d just want to batch-rename the original files to remove forward slashes from file names (although I realize that it’s not always feasible).
I don’t have a comprehensive explanation for this or when it applies but applescript can handle this situation automatically. However, maybe not when you begin with a posix path — presumably because this is a string.
I created a text file with your file name (and one line of text as its contents) on the desktop and then selected it. I find this method easier for this type of demonstration. You could use a file reference instead of an alias if desired (i.e. «class furl»)
Note that the alias retains the slashes in the name but when coerced to a posix path, they are displayed as colons. When referenced again as an alias, they are displayed again as slashes.
Finally, the read command works as anticipated.
tell application "Finder" to set selFile to selection as alias
--> alias "Macintar:Users:username:Desktop:An_example_file_//_to_make_hfs.txt"
set pps to POSIX path of selFile
--> "/Users/username/Desktop/An_example_file_::_to_make_hfs.txt"
tell application "System Events"
set ab to alias pps
--> alias "Macintar:Users:username:Desktop:An_example_file_//_to_make_hfs.txt" of application "System Events"
set selText to read ab as «class utf8» -- contents of selected file
--> "all occurrences of “//” with a unique combination"
end tell
Of course, unless you have a specific need to use posix paths at that junction, you could likely forego some of the coercion by working with file or alias.
The file name comes to my script in Posix form. But this discussion has made me realise that’s not a given. I might be able to control the nature of the path coming in.
However, what user sees as a “/” is only for display purposes. In the actual file name in the system, “/” is represented by “:” (when represented by POSIX path).
Forward slash has never been an issue in HFS paths.
I assume that Apple had to implement this switcheroo in OS X for backwards compatibility: users already had countless files with “/” created on the “classic” Mac OS and had to be able to keep using them.
Ideally, of course, forward slash should never be used in file names to avoid exactly these issues as well as compatibility issues with other platforms.
Oh yeah your example is a great demonstration why forward slashes should never be used in file names - even though they’re allowed on macOS.
Like I mentioned, I assume that Apple didn’t have a choice but to violate the POSIX forward-slash ban in order to preserve backwards compatibility with “classic” Mac OS.
When you obtain a path from an actual existing file (whether by AppleScript or Objective-C), then usually the “:” to “/” switcheroo works (which sometimes is useful to just tell the user to rename the file).
But combining paths artificially using hardcoded file names with forward slashes - like in your example - will sure just create a total mess.
Yes, it’s NEVER been possible to use colon in file name (including in the “classic” Mac OS) because it’s been the path separator in HFS paths.
Naturally, Apple didn’t change the ban on colon on OS X.
However, like I mentioned, they had to allow forward slashes in file names on OS X for backwards compatibility. So, as it seems, the “/” to “:” switcheroo was the best solution as the colon is the path separator in HFS paths while forward slash is the separator in POSIX paths. So you can switch them without creating a wrong path error (and vice versa - inserting them into the wrong path will always create an error).
Now, as you probably know, what you see in the Finder is NOT the actual file name. It’s a display name. You can get it in NSFileManager via displayNameAtPath: method.
In System Events it’s displayed name property.
Like I mentioned, the actual file name never has any forward slashes - in reality they are colons.
You can try this (while using paths of real files):
tell application "System Events"
displayed name of disk item "path:to:file//name.txt" -- file//name.txt
name of disk item "path:to:file//name.txt" -- file::name.txt
end tell
(BTW, the name property in the Finder dictionary will actually return the display name).
I agree. But I’m sure you realize that some 90%+ of Mac users have no idea what “POSIX” is and will use whatever characters they’re allowed to use by the OS.
I also agree that it would be nice if we didn’t have to use HFS paths.
However, for many years after introduction of OS X developers simply didn’t have a choice. AppleScript simply didn’t fully support POSIX paths (which applied to both Apple’s own products and 3rd-party software). For example, InDesign didn’t understand POSIX paths in AppleScript for many years. And even after POSIX paths became accepted, you still had to keep using HFS paths for backwards compatibility with earlier InDesign versions in your scripts.
As you know, many AppleScript calls return HFS paths by default and it’s not always practical to convert them to POSIX every time (plus sometimes you have to use that HFS path anyway).
Yeah I don’t think that any scripter in his right mind would intentionally use forward slashes to compose a file name in the code lol. All files with forward slashes in their names are named manually by the users. So developers just have to be aware of this and know how to deal with them when such files are encountered.