I’m modifying an existing script (not written by me) that tests for the existence of a file by asking the Finder for the container of a file, then appending the name of a file that is already known to exist PLUS an extension, like this:
tell application "Finder"
set test_file to choose file
set the container_path to (the container of test_file) as text
set the_extension to ".sxw"
if exists item (container_path & the name of test_file & the_extension) then
display dialog "Exists"
else
display dialog "Doesn't exist"
end if
end tell
This works everywhere except when the file being tested is on the desktop. That’s because (as far as I can see) the container of the file ends with a colon - EXCEPT when the container is the desktop, in which case there is no colon at the end.
So the workaround seems to be to add this block after setting the container_path variable:
if the last character of the container_path is ":" then
else
set the container_path to the container_path & ":"
end if
Is there a more straightforward to get this path into a variable, with the colon always at the end? The container_path variable is used in a half-dozen places in the script, and I’m afraid of breaking the script if I replace it with a POSIX path or something else. Thanks for any help
If you’re using the script you posted above, the container path should end with a colon even when the container’s the desktop. It does on my machines and I can’t think of anything that would prevent it. Are you sure that’s the problem? If it is, then apart from curing whatever’s causing it, your workround, or Shane’s reworking of it, is the only way to go. (I can’t resist offering a very slightly more efficient version, which tests the path directly rather than the extracted last character:)
if container_path does not end with ":" then set container_path to container_path & ":"
I’m more suspicious of your appending of an extension to whatever extension the test file already has ” which is what Hans-Gerd’s post is about. If your Finder preferences aren’t set to show name extensions, you may not be aware that the test file has one.
Thanks to everyone for those helpful messages. I should have explained more clearly what this script does (and it’s an existing script by someone else that I’m modifying, not a new script that I’m writing now, so I want to preserve as much of possible of the work that the original author did). I do understand that the name of existing file includes the extension (suffix); what I am doing is testing for the existence of a file that has the form (name of known file & “.html”).
The script uses the command-line wpd2html utility convert an existing WordPerfect file to a new file in HTML format. Here are the steps.
The user drops a file on the droplet (or chooses the file in Finder). The file might be named MyWPFile.wpd.
The script is going to create a new file named MyWPFile.wpd.html but it does not want to overwrite an existing file that already has that same name.
So it creates a string with the full path of MyWPFile.wpd, and appends “.html” to that string, and then tests whether a file named MyWPFile.wpd.html already exists
if such a file does exist, the script adds " 1.html" to the original filename, and tests for the existence of that file; if it does not exist, then the script uses wpd2html and creates a file named MyWPFile.wpd 1.html
So that is why I add the extension to the filename.
As for the presence or absence of the colon in the path of the container. Please run the following script:
tell application "Finder"
set test_file to choose file
return (the container of test_file) as text
end tell
Choose a file that is NOT on the desktop. The returned string ends in a colon.
Now run the script again and choose a file that IS on the desktop. The returned string does NOT end with a colon.
At least that is what happens on my 10.6.5 system. Nigel, are you saying that this should NOT happen?
I installed a completely fresh 10.6.5 system, and tested the script above. When I chose a file from the desktop, the path of the container DOES end in a colon - as it did for everyone else here.
The OS X system on which the path to the desktop did NOT end in a colon was a 10.6.5 system, but it was originally a much older system, certainly as old as 10.5, perhaps as old as 10.4. Somehow, I suspect, something went wrong in AppleScript during the many upgrades, and that led to the odd situation where the path to the desktop did not end in a colon.
I can’t believe I’m the only the person who ever encountered this problem, but I haven’t found anything about it anywhere else.
May I return to this question? I’ve found something very strange.
I installed 10.6.6 on a new hard disk, and reinstalled my software. I then ran the script in Yvan Koenig’s message in this thread:
set test_file to choose file
tell application "Finder"
return (the container of test_file) as text
end tell
When I choose a file on the desktop the path returned does NOT have a colon at the end (as I reported at the start of this thread).
However, on the same system, if I create another account, with none of my applications installed in it, and I run the same script in that account, then the script works correctly. The path reported for a file on the desktop does end with a colon.
I am trying to figure out what might be wrong in my own account that causes this non-standard behavior (reported path of a file on the desktop does NOT end with a colon). I have removed any Scripting Additions from ~/Library; this had no effect.
Can anyone think of anything else that might cause this? Thank you for any advice.
Have you considered avoiding the text coercion and concatenating altogether?
set test_file to choose file
set the_extension to ".sxw"
tell application "Finder"
if exists item (name of test_file & the_extension) in (container of test_file) then
display dialog "Exists"
else
display dialog "Doesn't exist"
end if
end tell
That will definitely work - thank you. But I hope I can figure out why the same script produces different results in two different accounts on the same 10.6.6 system. As I said, in one account, the colon appears at the end of the string; in my main account, it doesn’t appear. Very odd.
I’m really puzzled.
I never got the described behavior.
I guess that there is something odd in yourUser Account but I’m unable to guess what except maybe the availability of an odd OSAX in the folder :
Macintosh HD:Users::Library:ScriptingAdditions:
What is returning this alternate script ?
set test_file to ((choose file) as text)
tell application "System Events"
return (path of container of disk item test_file)
end tell
Yvan KOENIG (VALLAURIS, France) dimanche 16 janvier 2011 10:45:01
Your alternate test produced the correct result. I combined the two methods (Finder and System Events) into a single script, and here are the results. As you can see, the path returned by the Finder does NOT end in a colon, but the path returned by SystemEvents does, correctly, end in a colon.
Before running this, I restarted the machine with a “safe boot” (hold down the Shift key while starting up), so none of my startup items were running. I also removed the only file in the ~/Library/Scripting Additions folder (it was the 1Password osax). So I can’t imagine why the Finder acts this way in one account on this machine and not in another account.
Thank you, Yvan. I am going to go through my scripts and replace as many Finder “tells” as I can after this experience.
I am very curious about what is happening here. I have deleted the Finder prefs file, as you suggested, but it caused no change.
I am now creating a new account on the Mac that I use for testing (not for day-to-day use). I am gradually installing and running my software, and I am testing for the colon problem after each change. If I learn anything useful, I will post it here.
and the matching command for the other extended attributes.
Edit: and I see that I can remove these extended attributes for a whole folder with: xattr -d “org.BasiliskII.ExtendedFinderInfo” *
These attributes seem to have been added by the Basilisk II 68K emulator program, when I specified the path /Users/ as the “Unix” path for the emulator in the Basilisk II prefs file. I solved the problem by changing the “Unix” path in the emulator to /Users//Documents (though anything below the directory would probably work just as well.
I apologize to anyone who spent time trying to figure this out. Perhaps the extended attributes might be a clue to other oddities in Finder’s behavior in AppleScript?