Duplicate and rename

[fousthvk]

I know this has been asked a hundred times and I have searched and read a bunch of topics on it yet I can’t seem to grasp my head around the syntax…

set sourceFolder to "Macintosh HD:Users:efoust:Desktop:Source:"
set destFolder to "Macintosh HD:Users:efoust:Desktop:Dest:"
set thePrefix to "xxxxx"
tell application "Finder"
	set theItems to duplicate items of folder sourceFolder to destFolder
	--Rename the files just copied to the Dest and append thePrefix to beginning of filename.
end tell

Whats my next step it seems so simple and what I am trying to do really is. It will be extremely useful however because I will be adding this to a Filemaker database and the source, dest and prefix will be variable based on the FM Record.

[fousthvk]

I guess I just needed to post here to get my brain thinking…

Here is what I came up with that is super light weight.

set sourceFolder to "Macintosh HD:Users:efoust:Desktop:Source:"
set destFolder to "Macintosh HD:Users:efoust:Desktop:Dest:"
set thePrefix to "xxxxx"
tell application "Finder"
	set theItems to duplicate items of folder sourceFolder to destFolder with replacing
	repeat with curFile in theItems
		set originalName to the name of curFile
		set newName to thePrefix & "-" & (originalName)
		try
			set the name of curFile to newName
		on error
			display dialog "There was an error renaming files at the RIP" buttons {"OK"}
		end try
	end repeat
end tell

[Nigel_Garvey]

Hi fousthvk.

Welcome to MacScripter and well done for managing to solve the problem yourself.

Just for correctness, both path variables should have ‘folder’ in front of them in the ‘duplicate’ line. Presumably what you’ve done happens to work, but notionally it’s duplicating the items to the piece of text “Macintosh HD:Users:efoust:Desktop:Dest:” rather than to the folder the text helps to specify.

tell application "Finder"
	set theItems to duplicate items of folder sourceFolder to folder destFolder with replacing
	-- etc.
end tell

[fousthvk]

Thank I will keep that in mind.

[fousthvk]

Ok so now I have a problem… It seems when the source folder has only one item it won’t rename the item copied… but if there are 2 or more it does it just fine… I was able to do this to get it to work but it seems odd that I tell it count 0 when I’d expect the count to be 1.

set sourceFolder to "/Volumes/Repository/Eric Foust Inc./1000000009-Scott Test Garment Files/File for Print/360dpi 35lpi" as POSIX file
set destFolder to "/Users/efoust/Desktop/1. 360dpi 35lpi" as POSIX file
set thePrefix to "Jobi10545"
tell application "Finder"
	try
		set theItems to duplicate items of folder sourceFolder to folder destFolder with replacing
		set theItemCount to the count of theItems
		if theItemCount = 0 then
			set originalName to the name of theItems
			set the name of theItems to thePrefix & "-" & (originalName)
		else
			repeat with curFile in theItems
				set originalName to the name of curFile
				set newName to thePrefix & "-" & (originalName)
				try
					set the name of curFile to newName
				on error
					display dialog "There was an error renaming files at the RIP" buttons {"OK"} with icon 2
				end try
			end repeat
		end if
	on error
		--do nothing
	end try
end tell

[McUsrII]

Hello.

@fousthvk

I was able to do this to get it to work but it seems odd that I tell it count 0 when I’d expect the count to be 1.

This explains the behaviour:

set a to 5
set b to count items of a
--> 0

The thing is, it is allowed to count something that isn’t a list, and then it returns 0 items, this suggests that only a single file reference is returned, when there were only one item. There is a common convention with AppleScript that the return type may vary.

[Nigel_Garvey]

McUsrII’s saying that when there’s only one item, the Finder returns just a reference to that item instead of a reference in a list. Counting the reference returns 0, for some reason. It’s inconsistent behaviour and not ideal, but it’s been that way for many years.

In your case, the thing to do would be to coerce the result explicitly to list. That way you’ve got a list whether there’s one item or several:

tell application "Finder"
	try
		set theItems to (duplicate items of folder sourceFolder to folder destFolder with replacing) as list
		repeat with curFile in theItems
			--etc.

[fousthvk]

thanks Neil that makes sense…

[McUsrII]

Hello.

You should get yourself a 30-day free trial copy of Script Debugger (if that offer still exists), it saves a lot of time and agony.

Maybe ASoC Obj explorer, can do the same thing, then I’d try that first, because it will also work with AppleScript-Objective C, which is very much in the coming now adays.

[DJ_Bazzie_Wazzie]

@McUsrII

Maybe ASoC Obj explorer, can do the same thing, then I’d try that first, because it will also work with AppleScript-Objective C, which is very much in the coming now adays.

Don’t know if AppleScriptObjC becomes more popular. The difference is that you don’t need an running instance of an AppleScriptObjC application anymore. It’s indeed an improvement but it hasn’t changed the level of difficulty a bit. The threshold of learning AppleScriptObjC isn’t the running instance that was required but is the need to learn Cocoa (and partly Objective-C and C). I think that still applies, even after these improvements in usability.

ASObjC Explorer for Mavericks is an great tool to build script libraries with, but not only for AppleScriptObjC, also for plain AppleScript (event) handlers.

[McUsrII]

@DJ Bazzie Wazzie

@McUsrII

Maybe ASoC Obj explorer, can do the same thing, then I’d try that first, because it will also work with AppleScript-Objective C, which is very much in the coming now adays.

Don’t know if AppleScriptObjC becomes more popular. The difference is that you don’t need an running instance of an AppleScriptObjC application anymore. It’s indeed an improvement but it hasn’t changed the level of difficulty a bit. The threshold of learning AppleScriptObjC isn’t the running instance that was required but is the need to learn Cocoa (and partly Objective-C and C). I think that still applies, even after these improvements in usability.

ASObjC Explorer for Mavericks is an great tool to build script libraries with, but not only for AppleScriptObjC, also for plain AppleScript (event) handlers.

I am overly confident that it will become more popular, and if not permeate everything concerning AppleScript, so be present at a whole new level as it really gives access to System Resources in a whole new way. And maybe not everybody are going to develop handlers, though I think most scripters at least will use handlers with origin from ASobjC.

Yesteryears you were supposed to use ASObjC in pretty much dedicated applets, and that was it, now you can use it everywhere!

Now, I am not totally different from everybody, and this is something I know I want to use, and I’m not interested in sitting and waiting for someone to create the functionality I crave.

I don’t think it is that difficult to learn at all, but mileage varies.

Edit
If you are to obtain system up time without ASObjC then I guess it will be done far slower, (unless I have overlooked something in System Events) because you then will have to execute a do shell script.

framework "Foundation"
on uptime_hours()
	return ((current application's NSProcessInfo's new()'s systemUptime()) / hours as integer)
end uptime_hours

Nice to know about the event handlers, this means I can use a delegate for the current application from a library! Thanks!

[DJ_Bazzie_Wazzie]

@McUsrII

I am overly confident that it will become more popular, and if not permeate everything concerning AppleScript, so be present at a whole new level as it really gives access to System Resources in a whole new way.

My point exactly, there is nothing new under the sun named AppleScriptObjC

@McUsrII

Yesteryears you were supposed to use ASObjC in pretty much dedicated applets, and that was it, now you can use it everywhere!

You could use it anywhere before, only you needed it to run as an background application rather than loading it into your current running instance of AppleScript using the AppleScriptObjC framework.

@McUsrII

Now, I am not totally different from everybody, and this is something I know I want to use, and I’m not interested in sitting and waiting for someone to create the functionality I crave.

Are you sure

I understand, I’m using script libraries myself and finished my turning my pseudo script libraries into real script libraries. But it’s for own usage

@McUsrII

I don’t think it is that difficult to learn at all, but mileage varies.

It’s not that hard to learn how to sort an array, replace substrings in a string or renaming a file. For those simple tasks you don’t need AppleScriptobjC in the first place. No, it’s creating interfaces on the fly or drawing paths on your screen where you have to learn the limitations of AppleScriptObjC because only a limited amount of C structs are supported by the bridge like NSRect. To know that you have to be aware of the differences betweens Objective-C objects and C structs. There is more to learn than the instance and class methods of the basic objects when you want to make full use of AppleScriptObjC. Again for basic operations you don’t need it, so why so much trouble for the average scripter?

Don’t get me wrong, I love AppleScriptObjC. But I think it will only be loved by a fistful of AppleScripters even in Mavericks.

@McUsrII

Nice to know about the event handlers, this means I can use a delegate for the current application from a library! Thanks!

You’re welcome: Every handler with it’s custom terminology is an event handler. Pretty much the same as an handler in AppleScript-Studio.

[McUsrII]

Hello.

I am along your line, when it comes to the simplicity of use, and the limitations of ASObjC, so we must have something in common.

I am basically thinking of the Foundation framework, and not the AppKit. And I agree to that you may suddenly realize that you have to fork in an Objective-C class here and there, but that shouldn’t be so much of a problem, not here anyway, with the helpful and proficient community of the ASObjC forum.

I meant using ASObjC in the form of cherry picking, use the parts of it that are most convenient for scripts. I may not have found all the cherries yet. And I prefer Objective-C for applications, because I know what I get.

When it comes to libraries, I’ll continue with my script objects until I need to upgrade them. And I’ll never write a dictionary for my own use, as I see from the System Log, that my dictionary wouldn’t be the only one with a problem.
(By the way, I believe totally random four letter codes, conforming to that one must be uppercase to be the best practice for dictionaries, because then a clash is most improbable.)

I have started with organizing my Script Libraries Scripts, with java-package resembling name standard, that I am very happy with.

In the end, ASObjC can do a lot for “pure” AppleScripts, especially when it comes to the foundation framework’s functionality, but not for everything, like sorting, where Nigel has handler I haven’t found yet in Cocoa.
But regex’s without sed/awk seems to be an all good thing, and there are lots of other stuff, like alleviating the need for the Finder/System Events by NSFileManager, which are totally priceless!

I think it is going to take off!

[DJ_Bazzie_Wazzie]

@McUsrII

I am along your line, when it comes to the simplicity of use, and the limitations of ASObjC, so we must have something in common.

I’m sure we do

[Shane_Stanley]

@DJ Bazzie Wazzie

Don’t know if AppleScriptObjC becomes more popular. The difference is that you don’t need an running instance of an AppleScriptObjC application anymore. It’s indeed an improvement but it hasn’t changed the level of difficulty a bit. The threshold of learning AppleScriptObjC isn’t the running instance that was required but is the need to learn Cocoa (and partly Objective-C and C). I think that still applies, even after these improvements in usability.

There are a couple of other points, though.

First, it’s easier because many of the quirks no longer apply. For example, before Mavericks (and outside Mavericks libraries) you couldn’t say “alias somePath” – you had to say “somePath as alias”. The same goes for several other specifiers, like date and file. You have to use the read/write commands differently. Small things, but so easy to catch you out, and they add up.

Second, you couldn’t really separate things before: your project was ASObjC or not. Now you can do your ASObjC stuff in one place, and do your app scripting as normal. This is significant in that you can use your favorite debugger, and do your app debugging as usual. Before, once you went to ASObjC, you lost all that – NSLog() and Console were pretty much your debugging tools. You pressed run or double-clicked, and that was it. It also makes it so much easier to retrofit into existing projects.

Third, there have been several other minor improvements. You can use the log command now(!), for example. The path commands work properly in libraries. AS catches exceptions and presents error dialogs, rather than your app just crashing and leaving you to trawl Console.

All of the above makes it worth using just for (mostly) Foundation stuff, and not necessarily interfaces. It’s so much more accessible, on several levels. (And IMO it’s AppKit where Cocoa is at its most complex.)

And the other point is that there’s no reason to assume thing will stop there. I suspect the version parameter of the use AppleScript statement will get some work at some stage.

[Shane_Stanley]

@DJ Bazzie Wazzie

There is more to learn than the instance and class methods of the basic objects when you want to make full use of AppleScriptObjC

But who says you have to make full use of it?

for basic operations you don’t need it, so why so much trouble for the average scripter?

And the world only needs four computers

I’ve been using AS since it came out. I taught it for many years. And several times a year for most of those years, I’d see someone post a handler for that most basic of operations, changing the case of some text. Of course, none of them coped with Unicode, and most of them ignored accents, or accounted for a handful of them. And many of them were woeful on the grounds of efficiency too, doing things like calling both AS character and ASCII number on every character. At one stage I had a small collection of them.

You might be amazed at how much trouble that basic operation caused a lot of scripters. I suspect a library written by someone else, or even copy-and-paste, would have been a lot less trouble, regardless of the language.

[DJ_Bazzie_Wazzie]

@Shane Stanley

@DJ Bazzie Wazzie

for basic operations you don’t need it, so why so much trouble for the average scripter?

And the world only needs four computers

I’ve been using AS since it came out. I taught it for many years. And several times a year for most of those years, I’d see someone post a handler for that most basic of operations, changing the case of some text. Of course, none of them coped with Unicode, and most of them ignored accents, or accounted for a handful of them. And many of them were woeful on the grounds of efficiency too, doing things like calling both AS character and ASCII number on every character. At one stage I had a small collection of them.

Is that the only example code we can come up with

Let’s put that one in perspective: When I want to change case I simply want to replace characters that are in the language where I write in. Dutch is an Germanic language (like Afrikaans, English and German). So my text will never contain any French specific characters, what would I do with French files on machine. The only thing I need to do is using tr and extend the array with some additional characters that are used in my language. Easy, simple and works without installing an addition library.

My point was that I was referring to the average scripter, the scripters that I help and meet since I wrote AppleScript myself since Mac OS 8. The scripters I mention is someone who doesn’t use script debugger and write code for their daily software to ease things. Those persons are working mostly in the advertisement business or at schools and aren’t developers for a living. They’re considered AppleScript users and visit MS, member of the AppleScript-list or other fora, however the jump to AppleScriptObjC is just too high and not their ambition. That is according to my experience the average scripter.

In respond to that I keep to my statement “why so much trouble?”.

[McUsrII]

Hello.

There is a saying there is much to: where there is a will, there is a way.

What I put in this in this context, is that people may be “using” it, without the faintest idea, as long as it solves a problem for them, when they are motivated to solve something, they’ll learn exactly enough to implement it.

Some will then find new uses to it, and learn more about it.

[Shane_Stanley]

@DJ Bazzie Wazzie

Is that the only example code we can come up with

No, but it’s about as basic as you can get.

Let’s put that one in perspective: When I want to change case I simply want to replace characters that are in the language where I write in. Dutch is an Germanic language (like Afrikaans, English and German). So my text will never contain any French specific characters, what would I do with French files on machine. The only thing I need to do is using tr and extend the array with some additional characters that are used in my language. Easy, simple and works without installing an addition library.

And if you post it here, it’s useless to lots of people. And you “use tr” – hardly a tool of the average scripter.

Another example I would suggest is sorting, but I was thrown by your statement that “It’s not that hard to learn how to sort an array”. You clearly work with a much more advanced average scripter than me I don’t know where Nigel wastes all his time And then there is number formatting, when people don’t want values appearing in scientific format – the AS peccadillo everyone in the recent thread about thousands separators neatly side-stepped. Or date formatting. Oh, that’s right – they can learn more command-line commands, or find out about undocumented AS commands. No trouble there And they intuitively understand why script objects make repeat loops run at an acceptable pace.

My point was that I was referring to the average scripter, the scripters that I help and meet since I wrote AppleScript myself since Mac OS 8. The scripters I mention is someone who doesn’t use script debugger and write code for their daily software to ease things. Those persons are working mostly in the advertisement business or at schools and aren’t developers for a living. They’re considered AppleScript users and visit MS, member of the AppleScript-list or other fora, however the jump to AppleScriptObjC is just too high and not their ambition. That is according to my experience the average scripter.

FWIW, that’s largely the sort of person I’m thinking of too.

In respond to that I keep to my statement “why so much trouble?”.

I guess my answer is the same reason many of them got into something that was totally foreign to them in the first place: the pay-off. For most users, AppleScript itself is too much trouble. I still remember when I started scripting, and I knew nothing about it. But I saw snippets of code that promised to do things I needed to do more efficiently, and I copied and pasted them without having a clue how they worked. People copy snippets from here and there that use sed and awk and various other utilities, and happily use them without knowing the first thing about how they work. I suspect that over time a lot of scripters will be using ASObjC similarly, with very little clue (or care) about how it works. With libraries, they don’t even have to know whether a script uses ASObjC.