I am interested in learning more about the duplicate command’s behavior. Does one of the solutions below offer advantages over the others? I am also curious about other implications or nuances of a Finder file vs a System Events file.
set filePath to ((path to desktop as text) & "Test File.txt")
set folderPath to ((path to desktop as text) & "Test Folder")
tell application "Finder"
set finderFile to file filePath
set finderFolder to folder folderPath
end tell
tell application "System Events"
set seFile to file filePath
set seFolder to folder folderPath
end tell
--duplicate finderFile to finderFolder
--duplicate seFile to seFolder -- error
-- Finder
--tell application "Finder" to duplicate filePath to folderPath
--tell application "Finder" to duplicate finderFile to finderFolder
--tell application "Finder" to duplicate seFile to seFolder -- error
-- System Events
--tell application "System Events" to duplicate finderFile to finderFolder
--tell application "System Events" to duplicate filePath to folderPath -- error
--tell application "System Events" to duplicate seFile to seFolder -- error
I have some reflections as to the second part of your question, given that the terms for using the duplicate command is the same. (Given the routing surpressed option for Finder’s version, I gather the Finder version to be better to use over Networks, guessing totally unualified over this.)
The advantage of using system events commands where I can are at least two fold as I see it, I am posix/hfs independent, is the first, (less typing ). The other is that System Events doesn’t carry a lot of windows around that may need updates, so scripting System Events, doesn’t lead to a whole other set of “side effects”.
(Which may or may not slow down your scripts responsiveness, if it is more to it than just duplicating a file.)
But from the Dictionaries, it also seems that Finder is a tad more user friendly if you need aa reference to the new disk item. Hmmm I wonder how System Events duplicate files, with regards to item names.
On my side, I dropped the Finder for every tasks which are not related to the windows.
To do its duty, the Finder is supposed to trigger System Events so I feel logical to do that by myself.
Sometimes I drop System Events and use do shell script but it’s not always sparing time.
As ASObjC Runner is always loaded on my mac, I use its file dedicated functions when scripts are just for my needs.
Yvan KOENIG (VALLAURIS, France) dimanche 11 novembre 2012 18:15:31
But in this case you must reference the folder and file in the Finder before the System Events command will work, so it is almost reversed. I am curious if there is any advantage in doing this or if leaving the duplicate command to Finder is the way to go.
That’s to be expected if finderFile and finderFolder are Finder references. System Events has no idea what to do with them, so they’re passed to their owner.
But the point of the question is that because you can’t send the duplicate command if you reference the files from System Events, you must reference them from Finder first.
The only System Events option that works is:
tell application "System Events" to duplicate finderFile to finderFolder
That’s the way it works, but I don’t know about the “expected” part. If it doesn’t know what to do with what it’s being fed, wouldn’t it behoove System Events to supply an error?
I don’t see any usefullness of this, but of course, if you know there is only this copy in that folder, since you duplicate to a folder, then maybe it is faster, on the other hand, you have to send events from Finder to system events, or maybe you pick up the finder references first, before you do something in a System Events block, which then sends it back to finder?
A trifle untidy to us purists, to be sure. But then a lot of people put things into ‘tell’ statements which shouldn’t be there and their scripts often work. In this case, the references belong to the Finder and the Finder understands the ‘duplicate’ command, so it does the honours.
Another manifestation of this is the first commented-out command in adayzdone’s original script, which isn’t even in a ‘tell’ statement, but still works.
tell app "System events" to duplicate file hfsTxtFile to folder hfsTxtDesktop
… This command seems broken. Why should a simple command like this one, stop to work?
File and destination are specified in hfs text format, System events just fails (Mojave)
I mean of course I can, but don’t like to use the Finder or shell
Bash requires some extra work to deal with illegal characters and is longer than a simple “duplicate”
KniazidisR is aware of this, but to avoid any confusion, the following is from the AppleScript Language Guide:
The System Events duplicate command has never worked for me. The error message returned when using the System Events duplicate command is “Files can not be copied” and that does appear to be the case. It’s a bit odd, though, that the System Events move command works as expected.
Anyways, Joy has ruled out use of the shell and ASObjC, which seems to leave Finder.
The following classes respond to the move command:
disk item file file package property list file
disk alias folder XML file
It is very odd: no any information for the classes which respond to the duplicate command.
It seems that this command was planned to be implemented, but then it was abandoned, and in the dictionary developers forgot to indicate that the command is not working yet. And here we are racking our brains on what this command is doing…
