Dangerous script!

Hi Vincent,

I've tried to emphasize the following a few times before and most people just complain that they would like for things to work differently for them and that it just adds extra "unnecessary" steps to their scripts. The following "extra step" will help you prevent such things as overwriting your files or folders ever again in the future.

Applescript can be a very dangerous tool for the novice (or for the experts, for that matter) and, as such, you should try to start learning some techniques that could help you prevent such things from occurring again in the future. I could post a do shell script snippet here that (if run) would completely delete your current user's home directory with no warning at all! There are numerous script snippets that I could post here that would cause serious damage to your computer! Please heed the following advice and please do not take it as me protecting Apple in any way, shape or form! I agree that the script you posted is very dangerous indeed! I just know how to safeguard scripts so that things like what you experienced never happen to you (or others) again.

Here's my advice:
Whenever I use Applescript to save a file (when scripting any "saving" action) I use choose file name to help avoid problems like the one you had. Here's one way you could rewrite your script to make it fool proof for anyone to use:

set myTest to "tell application " & quote & "finder" & quote & return & "beep" & return & "end tell"
set DesktopPath to path to desktop from user domain
set SafetyNet to choose file name default location DesktopPath default name "myTest"
tell application "Script Editor"
make new document with properties {name:"Finder beep", contents:myTest, description:"Just beeps the Finder"}
compile document "Finder beep"
save document "Finder beep" as "application" in SafetyNet with run only
quit saving no -- or "yes" or "ask"
end tell

As you can see I tried to leave your script untouched except for adding the "extra steps" necessary to help you safeguard your files and folders.

Again, I in no way am saying the way Applescript in OSX works is perfect or completely safe for the average user. I am stating that you should be completely sure of the exact path to where a file is getting saved before running a script that could potentially overwrite a file, a folder or numerous files and folders all at once.

In the future (if I was you) I would try to avoid "hard encoding" paths into your scripts. It's a lesson I had to learn the hard way many, many times many moons ago. I still get bitten every now and then and have been scripting for a very long time!

I hope you take this the right way (the way I intend the information to come across). I'm not trying to come across as a "know it all" or to be a PITA to anyone! I'm just trying to help as always 😉

I thank you for posting such a dangerous script as you did. Posting scripts like these helps get them out into the open for people to see and realize that Applescript is not a toy.

Hope this helps...

Ouch! That is a mean one!

On the same subject I discovered a couple of Finders "Power Suite" scripts that can be bad as well. Finders "log out", "shut down", or "restart" commands can bypass, save before closing, of some apps if executed. Once someone saves the script it can be named and custom iconed to appear (disguised) like any run of the mill application.

Food for thought!

...Ron

Mac OS 9 is even less secure, as there's no user-level separation.

A user can do pretty much anything he or she wants to the system without any authentication at all, since there's no such thing as "true" privilege separation in OS 9. (OS 9 Multiple Users doesn't count. ;-))

In the future (if I was you) I would try to avoid "hard encoding" paths into your scripts.

Chachi, just how do you avoid hard encoding paths? I've just started to write my first Applescript, and I must admit I don't know how to do that. Can't find anything in Finder that seems appropriate.

The Applescript is intended to allow iPhoto 5 users to bypass the MakerNote bug that prevents iPhoto 5 from working with large collections of photos from several common brands of digital camera. All the real work is done by a readily available Perl script called rmmn-100 or exifcleaner, and if they have deep directories of photos, maybe a find -execdir command in Bash. However in the iPhoto discussions, it became obvious that some iPhoto 5 users with this problem were simply not going to even attempt to use Terminal. Some were even contemplating a return to their Windows PCs to get stuff done.

So I thought I would have a try at doing an Applescript that would run the Perl stuff. Thanks to help elsewhere in this forum, I have a test Applescript working. However I know where my Perl scripts live ( ~/bin ), and I know they have been chmod 755 so it isn't a realistic test of how it would work for another user.

If I am to set up things to be easy to use, I imagine I need to bundle the Perl script, and the Applescript in a DMG. But then I have no idea where the user is going to put the Perl script, nor whether it still has execute permissions. I figured I could probably do another Applescript to put the Perl script someplace that should exist (like the Desktop, or maybe /Library/Scripts or ~/Library/Scripts).

Meanwhile I came across an Apple warning about setting file paths badly in Applescript, plus this thread, all of which make me pretty reluctant about doing that. There must be better ways than what I have thought of, but so far I haven't encountered them. After all, most Mac programs seem to work no matter where they are.

There must be better ways than what I have thought of, but so far I haven't encountered them

Absolutely!

What I would recommend doing (since you're planning on distibuting the script along with your applescript anyway) is bundling the perl script within an Applescript saved as an "application bundle". You'll notice there's an option to save your scripts as such when you do a "Save" (on an unsaved script) or a "Save As...". The option is in the popup button to the right of "File Format:".

You could then access your perl script a couple different ways. Both ways would involve you telling your Applescript the exact path to the perl script. Here are a couple of examples:

1.) Launch "Script Editor" (obviously)
2.) Go ahead and save the script at this point (no code necessary yet)
--Give the script a name
--Select "application bundle" from the "File Format:" popup button
--If your script needs to perform actions and then stay idle put a
check mark next to "Stay Open" (not sure if you need this or not)
--Click the "Save" button
3.) Click the toolbar button named "Bundle Contents"
4.) Drag and drop your perl script onto the "Bundle Contents" window
(not into the "Scripts" folder)
5.) At this point you can use one of the following commands to
access your script from within your Applescript:

set PerlScriptPath to POSIX path of ((path to me) & "Contents:Resources:PerlScript" as string)

or

path to resource "PerlScript"

(of course you'd replace "PerlScript" with the actual name of your perl script)

This is where it can get a little bit confusing for some.

If you run the first of the two commands above from within the "Script Editor" itself you'll notice that the results that get returned look like this:
"/Applications/AppleScript/Script Editor.app/Contents/Resources/PerlScript"
This is because the "path to me" part of the script is referencing the "Script Editor" and not your script since you are running the script from within the "Script Editor" application. During the testing phase of creating a script like this I've found it's best to comment out that part of the code and temporarily (partially) hard code the path into the Applescript. In your case you already have a copy of the perl script residing in ~/bin, right? So you could do something like this:

--set PerlScriptPath to POSIX path of ((path to me) & "Contents:Resources:PerlScript" as string)
set PerlScriptPath to POSIX path of (path to home folder from user domain) & "bin/PerlScript" as string

Once you've thoroughly tested your script and you're sure it works correctly you could comment out the temporary part and uncomment the part of the script that points to the perl script that is bundled in your Applescript.

Is this making any sense so far?

If you used the second of the commands posted above you'd use something like this for testing:

--path to resource "PerlScript"
set PerlScriptPath to POSIX path of (path to home folder from user domain) & "bin/PerlScript" as string

Again uncommenting the first line and commenting out the second after you've completed your testing phase.

Let me stop here and see if I've completely confused you or if you're following me so far. Please feel free to ask me any questions you may have about doing this.

I hope the information I've provided comes across the way I'm trying to put it. It's so hard to explain some things without actually showing someone in person...

path to resource "PerlScript"

thanks! I just posted a thread about streamlining my script. The script I posted was an Application Bundle like mentioned above. Currently I have the path to the resource stated the long way (Path to me & "Contents:Resources:resourceName")

I'll definitely try the short way now.

Hi zwei,

The path to resource feature is greatly overlooked. It's such a handy feature too !

In Eric's case the code should of been written like this:

set PerlScriptPath to POSIX path of (path to resource "PerlScript")

It was late when I posted. What can I say ? 😉

Late last night it didn't make any sense, but it seemed a lot easier this morning. I did however find some anomalies. For example, on trying to drop my Perl script into the Script Editor Bundle Contents icon, it only seemed to work when I opened the drawer (however I admit that I still can't get used to dragging and dropping anything).

In the Bundle Contents drawer, there was what appeared to be a Scripts folder, so I dropped my Perl in there. I never could persuade my program to work until I moved my Perl script out of the Scripts into the main contents of the drawer. I tried all sorts of variations on Scripts/rmmn-100.pl ... Hmm, I just looked inside the Package Contents in Finder, and noticed Scripts already contains main.scpt. I take it that I was never intended to put anything of mine in the Scripts folder, because that is where my Applescript lives.

Plus how did you folks ever find out about path to resource? Or indeed any of the Applescript commands? I've tried looking in dictionaries without ever finding anything about PATH, so it must be part of the Applescript language. The manual on the Apple site seems to date from 1999, and the Applescript Missing Manual I have just doesn't seem to contain enough detail (or maybe it isn't in the index). There must be some simple way to get a list of the Applescript commands? Something like using Esc shift ? in Terminal to get a list of your available Unix commands?

Anyway, here is the core of the Applescript so far. I guess when I am happy I need to add some try and error stuff around it.

on run
display dialog "Drag copy of photos here to remove MakerNote"
set _files to choose file with multiple selections allowed
common routine(files)
end run

on open draggedItems
common_routine(draggedItems)
end open

on common routine(items)
repeat with currentItem in _items
set unixPath to the POSIX path of currentItem
display dialog unixPath
set PerlScriptPath to POSIX path of (path to resource "rmmn-100.pl")
display dialog PerlScriptPath
-- set unixString to ("/users/ericpc/bin/rmmn-100.pl -p -v " & quoted form of unixPath)
set unixString to (PerlScriptPath & " -p -v " & quoted form of unixPath)
-- remove -v option when script is OK so MakerNote is removed
display dialog unixString
-- Get rid of theResult and other display dialogs when all working
set theResult to (do shell script unixString)
display dialog theResult
end repeat
end common_routine

Thanks Chachi

how did you folks ever find out about path to resource?

Hi Eric,

It's in Standard Additions dictionary >File Commands.

I find the Applescript dictionary setup very un-intuitive, but using the library in Script Editor helps me (Script Editor menu>Window>Library or Cmd-Shift-L).

John M

Hi again Eric,

First off you're welcome. It sounds like you've made some really good progress with your script. Congrats 😉

I'm just confused by the problems you ran into. You said:

I did however find some anomalies.

I think you need to read a couple of the steps over again. In step #3 I stated

3.) Click the toolbar button named "Bundle Contents"

and then in step #4 I said

4.) Drag and drop your perl script onto the "Bundle Contents" window
(not into the "Scripts" folder)

As for these questions:

Plus how did you folks ever find out about path to resource? Or indeed any of the Applescript commands?

I would have to agree with what John said. Plus you can always come to this forum and ask questions. I constantly run across "new" tips and techniques all the time around here!

Keep plugging away at it. The more you use Applescript the more it just becomes second nature in a lot of ways...

It's in Standard Additions dictionary >File Commands.

Thanks John. That is nice. That looks like it will really help me with the missing commands. Although I'd still like to find say a book with an Applescript reserved words list.

I did just find (in System Files (from Old Mac) -> Help -> Apple Script Help -> toc.html ) a set of Help files for Applescript that seem totally different (more tutorial than the ones from Script Editor). Seems to be for 1.5.5, which I gather is old, however rather confusingly about Script Editor says it is using Applescript 1.1.

Chachi,
Can I plead terminal confusion? You did indeed say to click the Bundle Contents before dragging and dropping, and I totally missed it. Still, no harm done, and making a mistake will help me remember to open the drawer in future.

Likewise you did warn against using the Scripts directory in the bundle. I read it, and even put the Perl script where you (correctly) said. And then I thought a Scripts folder sounds like a wonderful place to put a Perl script. It will be nice and tidy, all hidden away in a folder that has the right name. So I moved it, and changed my Applescript to suit. Maybe I didn't get enough sleep last night after all.

Thanks to your help I'm getting even more ambitious. When using the Perl script from Terminal I've been using find . -name 'IMGP*.JPG' -execdir rmmn-100.pl -p '{}' \; to recurse through an entire iPhoto Library removing the MakerNote in photos that are not thumbnails (thumbnails don't have the MakerNote problem). However if I put this into an Applescript I will probably need to change the IMGP*.JPG line to suit whatever one of the six camera brands that exhibit the Maker Note problem is being used. I'm not sure self modifying Applescript is the right way to approach this. Maybe I'll leave this problem for next week.

Plus if I get that far, then I might as well then look at whether I can extract a photo from iPhoto (with all its title and comment and exif information) and put it into a new iPhoto library, since that is the only way I can see to fix an iPhoto Library with the excessive MakerNote information. Sounds like I will be haunting these forums for a while.

Can I plead terminal confusion?

That's for the unix forums, LOL. 😉

Sounds like I will be haunting these forums for a while.

It's definitely a great community of very knowledgeable people! Have fun rattling your chains around here.

Indeed, Ron, security is mostly about trust and education.

Apple has inserted such traps in several applications: also in TextEdit you can save in "Macintosh HD:Users:login:Documents:" and make your fat "Documents" folder into a nice UNIX executable of 4 KB.