I considered adding code to move all duplicates to a separate folder, but you could again have dupes, so I think your method of making a list is better in that regard. You will still have the files that "would have been dupes" remaining in the source folder, and you could add the line of code in your "on error" block
set label index of theItem to 2
Which would label it Red. Then you could easily find the files that were not moved.
It's a good thing you didn't put the code in to move the files from their original location.
Duplicate file names either means someone incorrectly named a series of images or someone has duplicated a folder of images and put it into another folder but left the original there.
The fun part is to figure out what happened in each case and how to fix it so just knowing what file name is the problem is more than enough to track down the issue.
I wish I knew AppleScript so I can automate all kinds of fun things but I've never been able to learn the language (I'm more familiar with C++ and mostly text based stuff). Sometimes I try and hack away at something but I usually give up because I can't figure out the syntax and how to use the variables the way I want.
Maybe we'll see about expanding this script in the future but Phtoshop/Imageready actions are working well for the other part of this at the moment
Sometimes I try and hack away at something but I usually give up because I can't figure out the syntax and how to use the variables the way I want.
It fools you because it leads you to believe that it "understands" natural language. It was based on Hypertalk and I have always admired how the Apple software engineers chose syntax terms that were incredibly appropriate to how a natural-language command would sound.
However, the coolest part is that it is a true object-oriented syntax that is easier to understand because of the "tell" verb.
The key to rapidly advancing to the stage where you can just whip out the code is to understand the object hierarchy - and the application dictionaries are terrible at this. So I use Late Night Software's Script Debugger which will let you stop and see what the elements of each object are and how they are referred to.
What other language could you write a cool statement like
tell application "Finder" to set theList to every item of desktop whose name does not end with "jpg"
It fools you because it leads you to believe that it "understands" natural language.
Ain't that the truth. I don't know all those natural language words to use: every item of desktop who name does not end..... gah!! I find C++ much easier but I don't know enough so maybe I just haven't seen any of the really horrible stuff yet.
Quote:
The key to rapidly advancing to the stage where you can just whip out the code is to understand the object hierarchy - and the application dictionaries are terrible at this.
That's where I get messed up. I can use the dictionary or record something but then I don't know all those natural language words to put them together. Oh great, that program has a command to do what I want.... now how do I use it?
Script Debugger is quite an investment to make without knowing applescript. I think I'll have to learn it the hard way.
Nope. But nothing is getting deleted - it just moves the "suspected" thumbnails to their own album so that you can peruse them.
Finding dupes would be another script, much more complex and would take a long time on big libraries. Better to use the Sort menu item and Sort by Title.
My pleasure. Keep 'em coming. I've been coding Applescript almost every day since it came out in 1993 with System 7 Pro. It still sometimes takes me an hour to figure out a particular syntax. Thank goodness for Script Debugger from Late Night Software.
People have to understand what the purpose of Automator is. It is not a general programming language. It is for the purpose of automating repetitive tasks that consist of several clearly defined steps - things like resizing all the photos in a folder and then passing the resized photos onto something else for further processing and then putting them in a folder - like an assembly line. If the task gets slightly complex or needs custom filtering or other decision-making steps, then you have to insert an Applescript step or just go with Applescript to begin with.
Automator has one very useful feature, however - and that is to put a workflow into the Contextual Menu. Unfortunately it only will do this for the Finder, PDF dropdown menu, and some others. So what I often do is make an Automator workflow for the sole purpose of wrapping an Applescript, so that it can appear in the Contextual Menu of the Finder.
Automator is used extensively by Leopard itself, in some of the new features, especially in the developer tools.
What other language could you write a cool statement like
tell application "Finder" to set theList to every item of desktop whose name does not end with "jpg"
It's weird when I think about it but I feel more comfortable writing something like:
list = []
for item in Finder.getDesktopItems():
____if item[-3:] == "jpg":
________list.append(item)
and yet when you see them side by side it makes you wonder why programming languages are so obscure. Maybe it's got something to do with it being more international. It might be incredibly hard for a foreigner to figure out an English Applescript.
Quote:
Originally Posted by freddyfredfred
I think I'll have to learn it the hard way.
Nope, Leopard is going to have Python and Ruby application scripting so Applescript shouldn't be a requirement any more.
On the subject of Automator, I've grown to like it but as lundy says you have to realise that it's a workflow builder. Once you understand what it's for, it can be quite useful. One thing it would be nice for is building application installers - move file x here and file y there etc.
One of its biggest flaws is that it's too linear though. I would have much preferred a node based setup where you join inputs like Shake does. This way you can split one output to do multiple things instead of making multiple separate workflows.
Comments
I considered adding code to move all duplicates to a separate folder, but you could again have dupes, so I think your method of making a list is better in that regard. You will still have the files that "would have been dupes" remaining in the source folder, and you could add the line of code in your "on error" block
set label index of theItem to 2
Which would label it Red. Then you could easily find the files that were not moved.
It's a good thing you didn't put the code in to move the files from their original location.
Duplicate file names either means someone incorrectly named a series of images or someone has duplicated a folder of images and put it into another folder but left the original there.
The fun part is to figure out what happened in each case and how to fix it so just knowing what file name is the problem is more than enough to track down the issue.
I wish I knew AppleScript so I can automate all kinds of fun things but I've never been able to learn the language (I'm more familiar with C++ and mostly text based stuff). Sometimes I try and hack away at something but I usually give up because I can't figure out the syntax and how to use the variables the way I want.
Maybe we'll see about expanding this script in the future but Phtoshop/Imageready actions are working well for the other part of this at the moment
Thanks for the help lundy, much appreciated.
Sometimes I try and hack away at something but I usually give up because I can't figure out the syntax and how to use the variables the way I want.
It fools you because it leads you to believe that it "understands" natural language. It was based on Hypertalk and I have always admired how the Apple software engineers chose syntax terms that were incredibly appropriate to how a natural-language command would sound.
However, the coolest part is that it is a true object-oriented syntax that is easier to understand because of the "tell" verb.
The key to rapidly advancing to the stage where you can just whip out the code is to understand the object hierarchy - and the application dictionaries are terrible at this. So I use Late Night Software's Script Debugger which will let you stop and see what the elements of each object are and how they are referred to.
What other language could you write a cool statement like
tell application "Finder" to set theList to every item of desktop whose name does not end with "jpg"
It fools you because it leads you to believe that it "understands" natural language.
Ain't that the truth. I don't know all those natural language words to use: every item of desktop who name does not end..... gah!! I find C++ much easier but I don't know enough so maybe I just haven't seen any of the really horrible stuff yet.
The key to rapidly advancing to the stage where you can just whip out the code is to understand the object hierarchy - and the application dictionaries are terrible at this.
That's where I get messed up. I can use the dictionary or record something but then I don't know all those natural language words to put them together. Oh great, that program has a command to do what I want.... now how do I use it?
Script Debugger is quite an investment to make without knowing applescript. I think I'll have to learn it the hard way.
Nope. But nothing is getting deleted - it just moves the "suspected" thumbnails to their own album so that you can peruse them.
Finding dupes would be another script, much more complex and would take a long time on big libraries. Better to use the Sort menu item and Sort by Title.
My pleasure. Keep 'em coming. I've been coding Applescript almost every day since it came out in 1993 with System 7 Pro. It still sometimes takes me an hour to figure out a particular syntax. Thank goodness for Script Debugger from Late Night Software.
BTW, lundy, what's your view of Automator?
BTW, lundy, what's your view of Automator?
People have to understand what the purpose of Automator is. It is not a general programming language. It is for the purpose of automating repetitive tasks that consist of several clearly defined steps - things like resizing all the photos in a folder and then passing the resized photos onto something else for further processing and then putting them in a folder - like an assembly line. If the task gets slightly complex or needs custom filtering or other decision-making steps, then you have to insert an Applescript step or just go with Applescript to begin with.
Automator has one very useful feature, however - and that is to put a workflow into the Contextual Menu. Unfortunately it only will do this for the Finder, PDF dropdown menu, and some others. So what I often do is make an Automator workflow for the sole purpose of wrapping an Applescript, so that it can appear in the Contextual Menu of the Finder.
Automator is used extensively by Leopard itself, in some of the new features, especially in the developer tools.
What other language could you write a cool statement like
tell application "Finder" to set theList to every item of desktop whose name does not end with "jpg"
It's weird when I think about it but I feel more comfortable writing something like:
list = []
for item in Finder.getDesktopItems():
____if item[-3:] == "jpg":
________list.append(item)
and yet when you see them side by side it makes you wonder why programming languages are so obscure. Maybe it's got something to do with it being more international. It might be incredibly hard for a foreigner to figure out an English Applescript.
I think I'll have to learn it the hard way.
Nope, Leopard is going to have Python and Ruby application scripting so Applescript shouldn't be a requirement any more.
On the subject of Automator, I've grown to like it but as lundy says you have to realise that it's a workflow builder. Once you understand what it's for, it can be quite useful. One thing it would be nice for is building application installers - move file x here and file y there etc.
One of its biggest flaws is that it's too linear though. I would have much preferred a node based setup where you join inputs like Shake does. This way you can split one output to do multiple things instead of making multiple separate workflows.