I am using the applescript included with 8.6 and get weird results from using the Duplicate command in Finder. Usually I get the original file as result, but sometimes I get {}. What I want to do is copy a file to the same folder and specify a new name, this should work out asset x to duplicate afile to afolderset name of x to anameIn this case x was the same as afile, which I already knew. Is there a workaround? Short of creating a temporary empty folder and copy the file into it and renaming it there? And his example gives a {} as result in thenewfile
tell application "Finder"
set x to file "a file on the desktop"
set thenewfile to duplicate x
display dialog (thenewfile as string)
end tell
This is bizarre, since the result should contain thepath to the copy, not the original and not an empty list.
tell application "Finder"
set x to file "Linux 18" of the desktop -- file on desktop
set thenewfile to duplicate x
display dialog (thenewfile as string)
end tell
-->"Operator:Desktop:Linux 18 Copy"
Works for me (with AS1.4.3 on OS9). Sorry I can’t help.
The “to afolder” is optional. A command to duplicate an item automatically places the duplicate in the folder with the original(and appends the word “copy” to the duplicate).
According to the Finder dictionary, the result of the ‘duplicate’ command is a reference “to the duplicated object(s)”. Strictly speaking, this does mean in English “a reference to the object(s) of which a duplicate has been made” - but it is rather ambiguously expressed. This seems to do what you want, though there may be better ways:
tell application "Finder"
set oldFiles to (get name of every file of afolder) as list
duplicate aFile to the desktop
set name of every file whose name is not in oldFiles to aname
end tell
I can’t tell what’s causing the {} result in the sample script. Do you actually have a file called “a file on the desktop” on your desktop?
The result should be the NEW file, but is not in AS 1.3.7, which is what I have. Not sure where to find 1.4. Interesting script. Thanks, I’ll try that.
That was just an example that I tried, with the name picked to indicate position and name.
" Usually I get the original file as result, but: sometimes I get {}." This is bizarre, since: the result should contain the path to the copy, not: the original and not an empty list.Yupp.:
tell: application "Finder"
set x to file: "Linux 18" of the desktop -- file on desktop
set thenewfile to duplicate x
display dialog: (thenewfile as string)
end tell
–>“Operator:Desktop:Linux 18 Copy”: Works for me (with AS1.4.3 on OS9).Nice, but it does not work for me. It must be a bug. I got 1.3.7 on MacOS 8.6:Sorry I can’t: help. “What I want to do is copy a file to the: same folder and specify a new name, this should work: out as set x to duplicate afile to afolder set: name of x to aname” The “to afolder”: is optional. A command to duplicate an item: automatically places the duplicate in the folder: with the originalYes, I knew that. ;-): (and appends the word: “copy” to the duplicate). mgNot neccessarily. If I was sure that it did, it would not be a problem. But international systems add different texts. Mine (swedish) adds “kopia av” in front of. And of course repeated copying results in differently named file.What happened was that I got a shock when I used the result of a duplicate operation to rename and instead of getting the files:“Original” and “Work file” got"Work file" and “Copy of Original” ie my original file got renamed. So this bug can cause all kinds of mishaps.I’ll try reinstalling AS just to make sure it is not some odd damage to the AS files.
That’s what it says in the AppleScript Finder Guide: (written in 1996) and it’s what you’d expect by: analogy with other AppleScript results. My point is: that the result of the command is exactly what’s: advertised in the Mac OS 8.6 Finder dictionary - a: reference to the duplicated object(s), not to the: duplicate one(s) As such, “serious duplicate: bug” is not the right way to describe it.Tthe description of duplicate from the Applescript Finder Guide:"RESULTA reference to the new object or a list of references."So, it is indeed a bug.: However, without knowing why it was implemented this way,: I agree with you that a reference to the duplicate(s): would be preferable.It is the only result that makes sense, as you already have the reference to the original objects and no good - your script while good, is very much a workaround - way of finding the duplicates otherwise.: Hope it helps!Thanks again. It worked. Here is the final code, courtesy Nigel Garvey and and some part myself, a duplicate that works under MacOS 8.6 and AS 1.37
on duplicatefile(originalfile, destinationfolder)
tell application "Finder"
set oldFiles to (get name of every file of destinationfolder) as listduplicate originalfile to destinationfolderset filelist to every file of destinationfolder whose name is not in oldFiles return file list
end tell
end duplicatefile