DropStuff Error

Scripting Forums AppleScript | Mac OS X
, ,
#1

Greetings, I am attemptimg to use DropStuff to stuff a folder of items and I am continually receiving this error when attempting to stuff the initial folder to another, separate, specified folder:

“DropStuff got an error: Can’t make some data into the expected type.”

I have tried several variants of the script:

tell application “DropStuff”
stuff {“Volumes:Joshua’s G4:Applications:Application Authorization”} to {folder:“Volumes:Joshua’s G4:Users:jtowle:Desktop:New”}
end tell

or

set myFolder to the quoted form of POSIX path of “Volumes:Joshua’s G4:Applications:Application Authorization:”

tell application “DropStuff”
stuff myFolder to {“Volumes:Joshua’s G4:Users:jtowle:Desktop:New.sitx”}
end tell

I realize that this should be a VERY simple script, but it’s aggravating me as to why I am having difficulty with it. What am I doing wrong?

Thanks for the help!

#2

This should work:

tell application "DropStuff"
stuff alias "Joshua's G4:Applications:Application Authorization" to alias "Joshua's G4:Users:jtowle:Desktop:"
end tell

Hope that helps,
Tom

#3

Perfect!

Thanks, tmckenna, I knew it would be simple. Why purpose does the “alias” serve. I know what an alias represents for the general Macintosh system, but I’ve never been able to understand why it’s necessary to designate an alias before a file or folder.

Thanks, again.

#4

You’re quite welcome.

When you you run into a problem with AppleScript remember that the AppleScript Language Guide is your friend. Here’s a link to the answer you are looking for: http://developer.apple.com/documentation/AppleScript/Conceptual/AppleScriptLangGuide/AppleScript.8e.html

There are also a number of books available which you can buy or get from your local library.

I suppose it depends how much AppleScript you want to know.

–Tom (who has read every AS book published in the last couple of years)

#5

That ‘to’ should be ‘into’.

Your “file or folder” is actually just a string. Placing the keyword ‘alias’ in front of it in the script turns it into an alias specifier. This compiles into an alias, which is what’s required by DropStuff.

An ‘alias’ in this case is a form of file reference that keeps track of its target file or folder, even if that target’s subsequently moved to a different location. For that reason, the target must actually exist at the time the alias is created ” either when the script’s compiled or when it’s run:

-- Compiled alias:
alias "Joshua's G4:Applications:Application Authorization"

-- Alias realised at run time:
set myPath to "Joshua's G4:Applications:Application Authorization"
alias myPath

An ‘alias’ in AppleScript terminology mustn’t be confused with an ‘alias file’, which is a special kind of file handled by the Finder and which is called an ‘alias’ in the Finder’s ‘File’ menu.

It’s often possible to use a ‘file specification’ to refer to a file that may or may not exist. This looks like an alias, but has the word ‘file’ instead of ‘alias’ and doesn’t track the target file’s (or folder’s) movements. If you liked, you could use a couple of these instead of the aliases in your DropStuff script.

The Finder and System Events have their own kinds of references for files and folders, though they both understand aliases as well (for the most part). Inside a Finder ‘tell’ block, an expression like:

… isn’t a ‘file specification’ (which may refer to either a file or a folder), but a Finder reference specifically to a file. Since only the Finder can understand it, you’d have to get the Finder to coerce it to alias or to file specification if you wanted to use the result in another application.

POSIX paths are also just strings (Unicode texts, actually) and are only understood as file/folder specifiers in shell scripts and by a few OS X native applications. I suspect their use will become more widespread on the Mac in the coming years.

I hope this hasn’t been too confusing. :slight_smile:

#6

Nigel,

I think you are confusing the DropStuff dictionary with the Stuffit Deluxe dictionary. Here’s what my DropStuff 9.0.1 dictionary says:

stuff‚v : compress a set of file system objects as a StuffIt archive
stuff list of alias : item(s) to be stuffed
[format StuffIt/StuffItX] : type of StuffIt archive to create (default: StuffItX)
[delete originals boolean] : delete the original files after successful archive creation (default: false)
[individually boolean] : archive each file as an individual archive (default: false)
[dont recompress boolean] : dont compress files that are already compressed (default: true)
[self extracting MacClassic/Windows] : platform for creating a self-extracting archive (default: MacClassic, StuffIt only)
[compression level better/faster/custom/none] : compression level to be used for the archive (default: better)
[password string] : a password to use for encryption
[ignore desktop files boolean] : ignore Finder files such as .DSStore (default: true)
[binhexing boolean] : encode the archive as a BinHex file (default: false)
[adjust extension boolean] : remove the “.” from the extension after BinHexing (default: true)
[to alias] : a location to place the new archive
→ list of alias : the created archive

And here’s what the Stuffit Deluxe dictionary says:

stuff‚v : adds items to an archive
stuff list of alias : item(s) to add to an archive
into reference : location within archive
[passphrase international text] : passphrase with which to encrypt the files
[deleting boolean] : deletes the original files after they are added to the archive
[replacing boolean] : replaces any items with the same name
[compression level maximum/medium/fast/none]
[compress aliases boolean]
→ list of reference : reference(s) to archive items added

Try this script:

set a to (choose file)
set b to (choose folder)

tell application "DropStuff"
	stuff a to b
end tell

Then try this script, except it won’t compile:

set a to (choose file)
set b to (choose folder)

tell application "DropStuff"
	stuff a into b
end tell

I hope this clears some confusion.

–Tom McKenna

#7

Hi, Tom.

That’s interesting! It’s the ‘to’ version that doesn’t compile on my machines. What version of DropStuff are you using? I have 7.0.3 on two machines and 8.0 on another. Both dictionaries look like this:

I don’t actually have StuffIt Deluxe.

#8

Aha! Apparently the dictionary has changed! (Who knows why…)

I am using version 9.0.1

Mystery solved!

–Tom McKenna

#9

You’re just a glutton for punishment, aren’t you Tom? :stuck_out_tongue:

In my experience, Tom, Mr G. can be many things - but is rarely confused. :wink:

I think the apparent contradiction comes from a change in DropStuff’s implementation/dictionary. (My old copy of DropStuff 8.0.2, for example, also specifies ‘into’.) Edit: Ah - I see that, while I was doing my bad impression of a typist, you discovered where the problem lies…

However, your mention of dictionaries is a timely and relevant one, since I’ve thrown them into the discussion below…

Excellent stuff, Nigel.

From the number of queries we see about this, it is a potentially very confusing area. I was going to attempt a clarification myself earlier, but ran out of time/steam. Perhaps this is just as well - since Nigel’s explanation is typically clear, concise and comprehensive. :slight_smile:

Part of the problem seems to be the sheer variety of possible specifiers (text paths, Posix paths, Posix files («class furl»), file URLs, file specifications, aliases, application-specific objects/references, etc.)

Besides striving to gain a better general understanding of the differences and uses, it’s also worth trying to determine what an application or scripting addition actually expects - by checking its AppleScript dictionary. (One way to do this, for anyone that doesn’t already know, is to select Script Editor’s “File/Open Dictionary…” menu item.)

Of course, even doing this may not always avoid confusion (and can sometimes actually add to it) - since some dictionaries have been known to tell lies. [Gasp! :o] However, if you don’t already know the required syntax for a particular command, the relevant dictionary is often the best place to start.

In the above case, for instance, the DropStuff AS dictionary tells us (among other things):

…which seems to offer the advice necessary to side-step any of the original problems.

#10

Yes indeed. :slight_smile: Perhaps someone thought that ‘to’ was more intuitive. I imagine the underlying token will have remained the same though, so that scripts won’t need to be recompiled.

What an intriguing statement… :wink:

Interestingly ” and annoyingly ” this doesn’t work with DropStuff 8.0 on my Tiger system. DropStuff’s ‘has scripting terminology’ is reported as ‘false’ and so Script Editor doesn’t offer it as a scriptable application. Neither does my dictionary-opening script in ScriptBuilders (the Tigerised update to which I must remember to post!). Script Editor will however open the dictionary if DropStuff’s file icon is dropped onto its own. Smile, on the other hand, does recognise DropStuff as being scriptable. I wish I knew how it did that… :confused:

#11

ROTFL!

I must be a glutton for punishment, as I consider you one of my good friends Kai. :stuck_out_tongue:

Anyway, you are right – Mr. Garvey is one of the most learned AppleScripters that I know. (Oh and you too, Kai!)

–Tom

#12

That’s a sure sign of masochism, if I ever heard one! :lol: :lol: :lol: (But the feeling’s quite mutual.) :smiley:

And yet somehow, he still manages to maintain a remarkable patience, understanding and modesty. (Nigel! You’re not supposed to be eavesdropping on this conversation!) :o

However, now that you’re here…

Typical! (I don’t really use the menu command myself, but it seemed the easiest method to describe at the time.) Now that I’ve checked, it doesn’t show up here, either - although I’d hope the later versions work better.

I wrote a dictionary-opener myself, too - mainly because I tired of watching a spinning beach ball when trying to check even a minor point of syntax. However, I quickly became frustrated on realising just how difficult it could be to determine whether or not a dictionary was available. (This was in the early days of OS X - and things have improved slightly since.)

Script Editor’s recent Library window is also a major step forward, since it allows one to build a list of frequently used/scripted applications and scripting additions - but I think I still prefer my own little home-made (and slightly more contextual) effort. :wink:

IIRC, this question may have cropped up elsewhere - but I don’t recall Emmanuel ever letting on how Smile can somehow spot an application’s scriptability better than, say, Script Editor. However, the Satimage scripting addition does have a Resources Suite - and I wondered if Smile might use a similar technology to detect AppleScript terminology…

I believe that some apps (notably carbon) still contain Apple event terminology extension (“aete”) resources to define their AS dictionaries - rather than a plist-based script suite (Cocoa) or the more recent, xml-based scripting definition (“sdef”) format. As far as I can tell, those apps that don’t disclose their scriptability quite so readily are based on the older format.

By way of experiment, I knocked together the following script which, while it may not cover all bases (I’ve not tested exhaustively), does seem to fill in some of the gaps left by “aete” resources:

to checkOSAX for osaxName
	if osaxName is not in ((list folder (path to scripting additions)) & ¬
		(list folder (path to scripting additions from user domain))) then ¬
		error "This script requires installation of the scripting addition \"" & osaxName & "\"."
end checkOSAX

on resourceFiles from pckgFolder
	set f to (pckgFolder as Unicode text) & "Contents:Resources:"
	tell application "Finder" to tell (files of entire contents of folder f whose name extension is "rsrc") to try
		it as alias list
	on error number -1700
		it as alias as list
	end try
end resourceFiles

on hasScriptingTerminology(f)
	tell application "Finder" to if f's has scripting terminology then return true
	if (info for f)'s package folder then
		repeat with r in (resourceFiles from f)
			if (count (list resources "aete" from r)) > 0 then return true
		end repeat
	else
		if (count (list resources "aete" from f)) > 0 then return true
	end if
	false
end hasScriptingTerminology

checkOSAX for "Satimage.osax"
hasScriptingTerminology(choose file of type "APPL" without invisibles)
#13

Ach. You should catch some of the people on the AppleScript-Users mailing list. They routinely and casually discuss “closures”, “OOP”, “scripting over networks”, “event handling”, and all sorts of other stuff that makes my eyes glaze over. (On the other hand, an unreasonably large number of them top post without editing quotes and are only interested in AppleScript for its ‘do shell script’ command. But I digress… :rolleyes:)

And then, of course, there’s kai, whose courtesy, brilliant AppleScripting, and inventive flattery are much appreciated by all. :wink:

Yee-harrr!!! That’s great! Do you mind if I use a version of that in my script updates? The minimal testing of it I’ve done so far suggests that it’s only packages with aete resources that aren’t seen as scriptable by Tiger’s Finder. Non-packages, and packages with other types of scripting resource, seem to be OK. Also, since the script itself only needs to determine the presence of an aete resource, not to read it, it may be OK simply to check for the word “aete” in the file ” thus avoiding the need for a third-party OSAX:

script kai
	on resourceFiles from pckgFolder
		set f to (pckgFolder as Unicode text) & "Contents:Resources:"
		tell application "Finder"
			try
				(files of entire contents of folder f whose name extension is "rsrc") as alias list
			on error number -1700
				(first file of folder f whose name extension is "rsrc") as alias as list
			end try
		end tell
	end resourceFiles
	
	on hasScriptingTerminology(f)
		tell application "Finder" to if (f's has scripting terminology) then return true
		set inf to (info for f)
		if (inf's package folder) and (inf's name is not "Stickies.app") then -- Stickies takes forever to scan!
			considering case
				repeat with r in (resourceFiles from f)
					try
						if ((read r from 1) contains "aete") then return true
					end try
				end repeat
			end considering
		end if
		return false
	end hasScriptingTerminology
end script

tell application "Finder" to set fred to (choose file of type "APPL")
if kai's hasScriptingTerminology(fred) then tell application "Script Editor" to open (fred as alias)
#14

…and sometimes even quoting an entire digest! :o

Aw shucks… :rolleyes: (Ray, what we really need for situations like this is a blushing emoticon!) :wink:

Please - be my guest, Nigel. (Goodness knows, I’ve nicked enough of your ideas in the past!) :stuck_out_tongue:

My experience so far has been the same. (The days of the old aete resources may be numbered - but they’re bound to linger for a while yet…)

:lol::lol::lol::lol:

While I haven’t looked into this too deeply yet, your sans-osax checking method seems like an excellent idea! With many resource types, text parsing could present a problem. However, “aete” is a somewhat unusual combination of characters - and it looks like it might be possible to get away with checking for just the ‘word’. Certainly the approach seems to have worked well in the brief tests I’ve tried so far. :smiley:

I see that you bumped into a scanning issue with “Stickies.app”. I encountered the same behaviour with a few other apps, too - and I guess this depends largely on the number of language project (.lproj) folders present in an application package. The problem isn’t apparent with those apps that declare their scriptability, since the ‘has scripting terminology’ check sidesteps it. Products like StuffIt, etc. don’t hold things up, either - because (in version 8 at least) they have only an “English.lproj” folder, which contains the aete resource (in a “Localized.rsrc” file). If later versions differ in this respect, I’d expect them to disclose their scriptability anyway.

That realisation got me thinking about why, if language project folders exist within a bundle, we should need to wade through every single one. We’re only looking for a single piece of information, after all. And if the resource is anywhere, it’s likely to be in the “English.lproj” folder (especially since AS features only an English dialect).

So I tried a variation of the script that checks only the “English.lproj” folder (if one exists). This idea seems to be working quite well - and it sure does cut down on waiting time! (I also played around with a tid-based alternative to checking for the presence of “aete”. On a typical resource file of about 200,000-300,000 characters, it seems a bit faster here than ‘contains’ - in spite of the speed-doubling effect of the ‘considering case’ block.)

Anyway - for what it’s worth…

script kai
	on resourceFiles from pckgFolder
		set f to (pckgFolder as Unicode text) & "Contents:Resources:"
		if "English.lproj" is in (list folder f) then set f to f & "English.lproj:"
		tell application "Finder" to try
			(files of entire contents of folder f whose name extension is "rsrc") as alias list
		on error number -1700
			(first file of folder f whose name extension is "rsrc") as alias as list
		end try
	end resourceFiles
	
	on hasScriptingTerminology(f)
		tell application "Finder" to if f's has scripting terminology then return true
		if (info for f)'s package folder then
			set d to text item delimiters
			set text item delimiters to "aete"
			try
				repeat with r in (resourceFiles from f)
					if (count text items of (read r)) > 1 then error number 501
				end repeat
			on error number n
				set text item delimiters to d
				if n is 501 then return true
			end try
		end if
		false
	end hasScriptingTerminology
end script

tell application "Finder" to set fred to (choose file of type "APPL")
if kai's hasScriptingTerminology(fred) then tell application "Script Editor" to open fred
#15

Firstly, apologies to any lookers on for the fact that this thread has strayed a little from its original topic.

Thanks, kai. It certainly does! It assumes, of course, that any aete resource will be in that particular folder (if it exists), but it seems a risk worth taking. (At least, we’ll know what to check if any exceptions turn up!) In fact, I’m feeling reckless enough to dispense with the ‘entire contents’ involvement as well.

Adobe Acrobat Reader 6.0.1, while not scriptable, has a folder “en.lproj” in place of the “English.lproj” one. For my script, I’m including a check for that too.

… and in spite of the fact that your implementation involves a recovery from a deliberate error! A slight change in geography to exclude that makes it faster still. :slight_smile:

With your handlers incorporated, my own dictionary-opening script works perfectly in Script Editor, but still misses DropStuff when run from Script Menu. It seems that the loop reference ‘r’ needs to be explicitly dereferenced (or a different kind of repeat used) in this environment. I don’t know why. :confused:

Thanks again. :slight_smile:

script kai
	on resourceFiles from pckgFolder
		set f to (pckgFolder as Unicode text) & "Contents:Resources:"
		considering case
			tell (list folder file f)
				if (it contains "English.lproj") then
					set f to f & "English.lproj"
				else if (it contains "en.lproj") then
					set f to f & "en.lproj"
				end if
			end tell
			tell application "Finder"
				try
					(files of folder f whose name extension is "rsrc") as alias list
				on error number -1700
					(first file of folder f whose name extension is "rsrc") as alias as list
				end try
			end tell
		end considering
	end resourceFiles
	
	on hasScriptingTerminology(f)
		tell application "Finder" to if (f's has scripting terminology) then return true
		if (info for f)'s package folder then
			set d to text item delimiters
			set text item delimiters to "aete"
			repeat with r in (resourceFiles from f)
				try
					-- r needs to be explicitly dereferenced when the script's run from Script Menu.
					if ((count text items of (read r's contents)) > 1) then
						set text item delimiters to d
						return true
					end if
				end try
			end repeat
			set text item delimiters to d
		end if
		return false
	end hasScriptingTerminology
end script
#16

It turns out to be nothing to do with dereferencing r. The apparent improvement when I did that was because I then recompiled the script on my Tiger machine instead of the other one on which I’d been testing it. I’m still none the wiser. :confused:

#17

Ditto. But the detour has been an interesting one (at least for me) - so I hope we’ll be forgiven for wandering a little… :slight_smile:

I’m inclined to agree. If any other exceptions arise, at least we should learn a little more about the possible permutations.

As if to prove the point about exceptions… :stuck_out_tongue:

(I now see that this is a common form with other Adobe applications, too: Photoshop, ImageReady, Adobe Reader, etc…)

Yup - certainly does! :lol:

I was going to say: It’s curious that, try as I may, I haven’t been able to replicate the Script Menu problem here. However, I was kinda relieved to read your latest post…

I’ve been noticing some minor compiling and saving issues here, which tend to throw up the occasional surprise - don’t know if there’s a connection… (I plan to do some further testing when I get a little more time.)

Nigel, it’s always a great pleasure to explore such matters with you! :smiley:

#18

I know I’m a retard for not being able to figure this one out, but how the hell can I zip to files to the same zip file with dropstuff
When it’s one file it works perfectly

tell application “DropStuff”
zip alias “Macintosh HD:Users:Oxy:Documents:!Office:!Report:!Today:daily.xls” to alias “Macintosh HD:Users:Oxy:Documents:!Office:!Report:!Today:”
quit
end tell

but when I try with zip list of alias I can’t get it to work in any way, I’d need another file to be zipped along with my daily xls it’s in the same directory and everything, and the only way I could find feasable is if I have finder copy those files into a new directory zip the directory then delete the directory, that would make me feel like a moron every time I ran the script so that’s out of the question, can some please help me with this one… I’m drawing a blank, I’ve tried the {,} and the , and the & and whatever ways to seperate them but I always get an error message and I’m told to get lost…
thanks…

#19

Unless it’s something else that’s changed since version 8.0, you use DropStuff to stuff and DropZip to zip.

I’m not sure whether you’re saying you want to zip/stuff two files into a new archive each time, or whether you want to add a new file to an existing archive. I think you mean the former:

tell application "DropStuff"
	stuff {alias "Macintosh HD:Users:Oxy:Documents:!Office:!Report:!Today:daily.xls", alias "Macintosh HD:Users:Oxy:Documents:!Office:!Report:!Today:my other file.xyz"} -- 'to' parameter not needed if stuffing to same folder
	quit
end tell

However, you won’t be able to compile the aliases directly into the script unless the files exist at the moment of compilation. You can either change ‘alias’ to ‘file’, so that you get file specifications instead of aliases, or you can get the aliases (or file specifications) at run time:

set todayPath to (path to "docs" as Unicode text) & "!Office:!Report:!Today:"
tell application "DropStuff"
	stuff {alias (todayPath & "daily.xls"), alias (todayPath & "my other file.xyz")}
	quit
end tell

Maybe that should have been “get stuffed”… :wink:

#20

Dude you rock what I was looking for really was how to add more then one alias, what you showed me with this
zip {alias “Macintosh HD:Users:Oxy:Documents:!Office:!Report:!Today:daily.xls”, alias “Macintosh HD:Users:Oxy:Documents:!Office:!Report:!Today:to_use.fp7”}

thanks!
cheers!