Discovering Automator by Hanaan Rosenthal • Automator, A Mac OS X Tiger automation app for the rest of us
Chapter 6: System administration and other Actions
Automation has always been associated with administering Macs. People whose job it is to manage multiple computers have always relied on automation to make their work easier. With all the tools out there that can help administrators do their job better and faster, Automator has a lot to offer.
This chapter looks at different ways in which Automator can be used to perform tasks commonly associated with Mac system administration.
Creating disk images
The first workflow you’ll create will start out with a user-specified folder. The folder will be made into a disk image and the disk image is then burnt to disk.
Creating disk images and burning them to disk is a common way to back up data that can be later restored to its original form.
To start, create a new workflow.
The first step in the workflow will be to ask the user to pick a folder to burn. The perfect action for this is the “Ask for Finder Items” action. This action is cool because it allows you to specify what type of items you want the user to select, and specify if they can select multiple items or not.
In this case we want the user to select a single folder. Therefore, after you add the “Ask for Finder Items” action to the workflow, customize it to look like the action in Figure 5.
Figure 1. The “Ask for Finder Items” action, customized for our workflow needs.
As you can tell from looking at Figure 1 and as would be expected, the result of the action is a reference to files and folders. In our case, the list of file references passed to the next action is a single folder selected by the user.
The next step of the workflow will be to create a disk image out of the folder selected in the previous action.
Add the New Disk Image action to the end of the workflow, and customize it as follows:
From Size, select the disk size you will use for burning. Since this is only an exercise, select 660MB CD-ROM.
In Save As, type “temp_image.” This name is not really important since we will be discarding the image after we burn it to disk.
From the Where popup menu, select Desktop.
From When Done, choose “Leave mounted…” This will ensure that the disk image itself will be returned, not the disk image file. This will allow us to easily eject the volume after completion.
About Volume name, type in some default name, but this field will be left up to the user to fill in every time the action runs. If you know that you want the volume name to always be the same, then simply enter the name you want. Otherwise, follow these steps:
In order to let the user enter a potentially different volume name every time the workflow runs, you have to tweak the Run options.
1. Show the Run options.
Expand the Options disclosure triangle at the bottom left corner of the action pane.
2. Check the “Show Action When Run” checkbox.
3. Click the “Show Selected Items” radio button.
By now, you have a list of the action’s interface items which you can have individually shown when the workflow runs. Make sure that only the Volume Name check box is checked, and the rest are unchecked. This way, when the workflow runs and this action comes up, the user will see a dialogue box with only the Volume Name text field available for editing.
Figure 2 shows the fully customized “New Disk Image” action.
Figure 2. The fully customized “New Disk Image” action.
At this point you should have two actions in your workflow. To make better use of screen real estate, collapse both actions by clicking each action’s disclosure triangle, which can be found between the action’s number and the action’s name at the top left corner of the action pane.
Finally, the “Burn a Disc” action will be added. This action is found under the System category in the Library column. It is, however, easiest to type the word “Burn” in the search field.
Customize the action by entering a disc name. Notice that you can have the date added to the end of the disc name. This can help distinguish between the discs later on.
Figure 3 shows the “Burn a Disc” action after I customized it, preceded by the first two actions in the workflow.
Figure 3. The customized “Burn a Disc” action.
Housekeeping
After the disk image and burning was accounted for, we need to bring the Mac back to its previous state, as in not to piss off anyone. People love to come back to their Mac and find mounted disk images and various unrecognizable files and folders on the desktop…
To clean up after us, we need to eject the disk image and trash the disk image file.
Ejecting is easy—just add the Eject Disk action to the end of the workflow. Since the Burn Disc action returns a reference to the files it burnt, and the file it burnt is the disk, the Eject Disk action will just take that disk and eject it.
Deleting the disk image file that still remains on the desktop may be a bit trickier. We first have to use the “Get Specified Finder Items” action to specify the disk image file, and then use the “Move to Trash” action to delete the file.
The easiest way to specify a file is when that file already exists. For this reason, you should go ahead and run the workflow. If you want, you can disable all the actions after the New Disk Image action.
After running the workflow you should have a disk image file named “temp_image.dmg” on your desktop. Drag it right to the workflow window. This will add the “Get Specified Finder Items” action. Next, add the Move to Trash action, to move the resulting file to the trash.
Testing… maybe not this time.
Since running this action requires that you actually burn a disc, you can skip it if you want.
However, since we’re about to add another cool action to the mix, why don’t you go ahead and collapse all the actions to save space.
Adding AppleScript validation
One place where this workflow can go very wrong is in the case where the folder you’re trying to burn is larger than 660MB. To prevent this from happening, I will show you how you can use AppleScript to validate the size of the folder before you even create a disk image out of it.
For this purpose I will use the Run AppleScript action. Add the Run AppleScript action after the Ask for Finder Items action. This will cause the folder the user chooses to be passed directly to the Run AppleScript action where we can examine it.
After you added the Run AppleScript action (and collapsed all the actions), your workflow should look like the one in Figure 4.
Figure 4. The workflow up to this point, with the Run AppleScript action.
Since the variable ‘input’ has a list with a single item, you should first extract that item and assign it to a separate variable, like this:
Set folder_path to item 1 of input
Next, you will get the size of the folder and compare it to the maximum number of bytes allowed. Since the disc we burn on has 660 MB, the maximum number of bytes is:
660 * 1024 * 1024.
Here’s the script that does that:
set folder_size to size of (get info for folder_path)
if folder_size is greater than (660 * 1024 * 1024) then error "Folder too large"
The finished Run AppleScript action looks like the one in Figure 5.
Figure 5. The finished AppleScript verification script in the Run AppleScript action.
More about the Run AppleScript Action
One of the nice actions in Automator is the rename files/folders action. Man, it lets you do anything you want: Add a serial number to files, add the date, etc. One thing you can’t do is simply give a file a new name, just any name! “George,” “Monique,” “Jobs BU,” whatever it is that you want.
What you will do now is remedy that by creating an AppleScript action that will change the name of the first file that is passed to it.
The script is very simple, and it goes like this:
set file_path to item 1 of input
tell application “Finder” to set name of file_path to “Anything”
Yes… you will have to actually insert the name of the file, at least in this iteration of the script, but for the amount of code, it’s worth it.
The Run AppleScript action that will rename a single file appears in Figure 6.
Figure 6. This Run AppleScript action will rename a file or folder that is the output of the previous action.
To test this, drag a file you don’t mind renaming from the Finder to the workflow, make sure that the resulting “Get Specified Finder Items” action is the first action, and run the workflow.
Performing UNIX Shell scripts with Automator
The ability to execute UNIX commands on Mac OS X is undoubtedly one of system administrators’ most beloved new additions. Imagine—overnight Mac users had the ability to execute nearly any UNIX command out there.
UNIX is a command-line operating system owned by SUN Microsystmes. UNIX first appeared in XXXX and is a favorite among server administrators due to its strong security features and well thought out multi-user environment.
Automator lets users of two levels take advantage of UNIX Shell scripts; by using the “Run Shell Script” action, and by creating Shell script-based actions.
In our exercise we will skip the latter. While authoring your own actions is not difficult, especially if you know some AppleScript and Shell script, it does require a whole other set of tools aside from just Automator, and some more room in the book, which we don’t have.
The “Do Shell Script” action
Much like using the “Run AppleScript” action, in order to use the “Run Shell Script” action, you have to be familiar with UNIX Shell scripting.
The “Run Shell Script” action’s main text field is where the actual Shell script text goes. You can see it in Figure 7. On top of that you can define which UNIX language your script is written in. There are several flavors of Shell as well as other scripting languages such as PERL and Python.
Figure 7. The “Run Shell Script” action. The open popup allows you to pick the language your script is in.
For our example, we’re going to leave the default settings in both popup menus.
The workflow we’ll create with the “Run Shell Script” action will ask the user to enter a single Shell script command, and open a new TextEdit document with the man pages for that command.
Man oh man, what are man pages?
Just type “man man” in the Terminal, and you’ll know! The UNIX ‘man’ command is short for the word ‘manual.’ Typing the word ‘man’ followed by a command will display the manual pages for that command. To try it, open the Terminal application; it should be in your Utilities folder. Type “man ls” and then type return. The manual pages for the ls command will display.
1. Create a new workflow.
2. Add the “Ask for Text” action.
In this action the workflow will require the user to enter a single UNIX Shell command. Fill it in as shown in Figure 8.
This action will pass the name of the Shell command to the next action.
Figure 8. The customized “Ask for Text” action in the workflow.
3. Now, add the “Run Shell Script” action.
In the main text field, type this:
man "$@"
Leave the rest in the default position.
What you’re actually looking at is the word ‘man’ followed by whatever is passed from the previous action. When the action executes, the “$@” portion will be replaced by whatever the user typed in the previous action.
Note that while the Shell script will run properly, you may want to replace it with this, slightly longer version:
man "$@" | col –b
This version removes the underscore and other formatting from the text, which appear funny outside of the Terminal application.
4. Add the “new TextEdit Document” action.
Finally, the text that the Shell script will produce, which will hopefully contain the man pages text, will be converted into a new TextEdit document.
When you’re done, your workflow should look like the one in Figure 9.
Figure 9. The finished workflow.
Now run the workflow.
In the first dialogue box, type a command such as cp (copy), and click “Get it” (or press Return).
A new TextEdit document should appear with the manual pages for the cp command.
Changing preferences with Automator
Another cool thing you can use the Run Shell Script action for is changing preferences.
To change any preference of many applications—certainly any Apple application—you can use the Shell command “defaults write.”
To find out what to put there, you can open the actual preference file and poke around. For example, I heard that Safari has a hidden ‘Debug’ menu that’s a cool hack to turn on. To figure out the exact wording for it, I went to my Preferences folder in the Library folder that’s in my user folder. Then, I found a file called “com.apple.safari.plist.” I double-clicked it.
The com.apple.safari file has the “plist” name extension, which stands for Property List. When you double-click a file that file it will open in the Plist Editor application.
After it’s open, I searched for something that reminds me of a debug menu. I found this line:
IncludeDebugMenu String 1
This was definitely it! I copied the name of the property itself and noted that its value can be a ‘1’ or a ‘0.’ You can see it in figure 10.
Figure 10. The plist file open in Plist Editor with the property we want selected.
Using the “defaults run” command
Next, you will create a workflow that will include a single action that will turn the default menu on or off.
1. Create a new workflow.
2. Add the “Run Shell Script” action.
Write the following line into the main text field:
Defaults write com.apple.Safari IncludeDebugMenu 1.
You can add either a 0 to turn the default off, or a 1 to turn it on.
The finished action, which makes up the entire workflow, is shown in figure 11.
Figure 11. The final action that adds the Debug menu to Safari.
Next, with your amazing knowledge you got at the start of this chapter, create a workflow that will ask the user to enter either a 1 or a 0, and turn the default on or off based on that info.
Man, I’m glad this one’s done…
Depends on your level of comfort with AppleScript and Shell scripts, this chapter may have gone right over your head. If you’re still reading, however, it shows that you probably got something out of it and stuck with the chapter. Good work!
In the next chapter I will share with you a few tricks for debugging workflows.
Ho, sorry, what’s debugging? Read on and see :-)