Mac in the Shell: Automation Potpourri
Volume Number: 23 (2007)
Issue Number: 06
Column Tag: Mac in the Shell
Shell and GUI scripting come together
by Edward Marczak
Last month, I gave an overview of some commands that I felt just didn't have the coverage and documentation that they deserved. The theme this month is commands that enable us to tie our shell scripts into the GUI. While I'm an advocate for good ole bash scripting, there are times when it's easier or better for some reason to tie in a GUI app. Think about scripting Safari, Address Book or Excel using familiar utilities in the shell. What about incorporating an AppleScript into a workflow with data piping in and out of it? If that sounds like a panacea, read on!
Under OS X, AppleScript is the clear reach-into-just-about-anything scripting technology. Why choose bash scripting over AppleScript? Let me enumerate some ways:
Existing stock snippets.
Ability to do things that AppleScript alone can't do.
Since the addition of 'do shell script' to AppleScript, there's little we can't coerce it into doing. This allows us to call a shell script from within AppleScript and return the results. What a powerful combination. That's great when the logic and script itself lie mainly in AppleScript. However, what if the situation were reversed? What if you have a lengthy shell script that needs to utilize an AppleScript? Enter 'osascript'.
osascript allows us to execute AppleScript commands and scripts from a standard shell. In the it's-getting-better-all-the-time category, as of 10.4 ("Tiger"), you can pass arguments into osascript, and AppleScript can pick them up in the 'argv' variable. It can run simple AppleScript commands all in one shot, or, it can run a script file. Let's see an example:
osascript -e "tell application \"Safari\" to launch"
That's about as simple as it gets. Standard shell conventions apply, so make sure you escape quotes and other special characters. The "-e" flag is used to denote a 'command,' or line in the script. Scripts that need multiple lines need multiple "-e" flags. For example, look at this command:
osascript -e 'tell application "Finder"' -e 'make new Finder window to folder "Applications" of startup disk' -e 'end tell'
Three lines of AppleScript, three "-e" switches. Note the use of single quotes here to avoid the pain of escaping double quotes. Naturally, you probably want to put lengthy or complex scripts into their own file. So, the previous example could have been its own file:
tell application "Finder"
make new Finder window to folder "Applications" of startup disk
This could then be invoked as "osascript new_win_app.scpt". Pretty handy. (Of course, this contrived example could be replicated easily in the shell alone as "open /Applications").
The Real Power
So, rather than come up with anything too contrived, let's explore where you may really use this. Let's take a look at a script that, in part, I really use.
Once upon a time, I had a script that mashed and mangled a bunch of data nightly. It would get this data from various data sources: MySQL, text files and the web. For the web sources, I simply used curl to fetch the data I needed as CSV files. Well, one day, my script stopped working. Why? Security. The web site in question required a certain login sequence, and tokens were generated for each form and page load so they couldn't be forged. Consequently, I needed a 'real' browser to do this part. Safari and AppleScript to the rescue. I was able to keep my shell script in place and largely untouched. I did need to swap out the curl calls, of course, and replace them with osascript auto_web_dl.scpt. The AppleScript file scripts Safari to load pages, click links and save the resulting file. Let's dissect:
on run argv
tell application "Safari"
-- Initial load
set URL of document 1 to "http://some.example.com/page/"
-- click the link
-- load the reports verification page
set URL of document 1 to "https://setup.example.com/¬
-- fill in the values
-- get the reports page
set URL of document 1 to "http://some.example.com/accounting/¬
in document 1 is "complete"
-- save the contents
set theSaveName to "acct_nightly.csv"
set theSavePath to (path to desktop folder as string) & theSaveName
tell application "Safari"
save document 1 in file theSavePath
tell application "Finder"
if file (theSavePath & ".download") exists then
set name of file (theSavePath & ".download") to theSaveName
(A big thank you to Ben Waldie from automatedworkflows.com for teaching me how to get Safari to save a plain text document! Not being an AppleScript person by nature, I just couldn't nail it down).
# Grab initial MySQL data
mysqldump -u db_user...> /data/table1.csv
# Grab web data
curl LO http://financialinfo.example.com/stocks.php?id=2345
# Grab accounting data
# Process results
More than just being able to call AppleScript from the shell, there are several ways to pass variables between the two environments. The first is a natural extension of what you know from bash. Simply put the bash variable on the command line:
$ osascript -e 'tell application "Finder"'¬
-e "display dialog \"Hello, $USER\"" -e 'end tell'
This will display a dialog box in the Finder containing the name of the currently logged-in shell user. Notice also, that when this is run, osascript returns values to the shell. Again, of course, you can use or discard these values as the situation dictates. Note that this is a valid way to pass data out of AppleScript and back into the shell.
Look at the possibilities this opens up! Take, for example, the following script:
for user in $(dscl /LDAPv3/127.0.0.1 -list /Users)
ma=$(dscl /LDAPv3/127.0.0.1 -read /Users/$user mail)
osascript -e "tell application \"System Report\" process $ma"
Here, we use bash and dscl to pull all users from Open Directory and then feed each of those into the fictitious application "System Report".
Another way to pass data between the two environments is via environment variables. AppleScript will happily reach out and grab environment variables from a shell using the system attribute variable. Let's say each user on the system has environment variable defined for their favorite color called, "my_color ". Without passing it in as an argument, AppleScript can access it like this:
set favorite_color to system attribute "my_color"
You can then go on and have AppleScript make decisions based on your new variable.
Finally, you can pass and values into the AppleScript as arguments. Given the following AppleScript:
on run argv
tell application "System Events"
repeat with currentArg in (every item of argv)
display dialog currentArg
It could be called like this:
osascript asarg.scpt mike bill joe
This will cause three dialog boxes to appear, each containing one of the arguments passed in.
The trick here is wrapping everything in the "on run argv" block. Since argv is an AppleScript list, you can access any element directly. For example, argument one is simply, "item 1 of argv".
I hope this short, but important topic, stirs some ideas in your head. These techniques truly make the scripting environment boundless. While there are many, many cases where you can script a workflow entirely in bash, or entirely in AppleScript, they are also many reasons to integrate the two. I talk consistently about remote management and troubleshooting of Macintosh systems. This is yet another great weapon in your arsenal. With only command line access, you can now launch applications, interact with them, and the user sitting at the console.
Using osascript also allows AppleScript into places that it is usually not allowed in. Think about a user interacting with a web page, and one of their actions runs an AppleScript. You can also use osascript to interact with users at important times. You can display a dialog box prior to running a CPU intensive cron job. This trick also comes in handy to alert users of actions being taken during login hooks.
One thing to note, though: while the data coming out of osascript is on stout, osascript has no concept of stdin. So, you need to use one of the techniques covered here to get data into an AppleScript. You just can't pipe your data in. (OK, in all fairness, you could get data into an AppleScript by reading a file or through sockets, etc. just not via stdin!).
Don't forget: interaction with osascript isn't just limited to bash and its constructs. Take a look at this great example from Apple's own, "AppleScript Overview":
osascript -e 'tell app "Address Book" to get the name¬
of every person' | perl -pe 's/, ¬
/\n/g'| sort | uniq d
This one liner will output duplicate entries from your address book. While I'm sure this could have been scripted entirely in AppleScript, it's unlikely that it would have been as concise or elegant as this one-liner.
The point is simple: mix and match as needed to solve the problem at hand. You have many varied tools at your disposal, each with particular strengths, advantages and weaknesses.
Media of the month: It's Johnny Cash month! If you've never listened to, "At Folsom Prison", do yourself a favor and experience it. If you know virtually nothing of the man, go rent "Walk the Line".
See you next month, post WWDC!
Ed Marczak owns and operates Radiotope, a technology consultancy specializing in automating business processes and enabling communications between employees and clients. Communicate at http://www.radiotope.com.