DirectNET

Data Center Management Solutions including UPS Systems, Data Center Cooling, KVM over IP & IP Power Strips, Server Racks and Server Rack accessories; KVM Switches and KVM Extenders; Rackmount Monitors and Rackmount Keyboards.


NAVIGATION
Home
Store
INSIDE MAC
Television Shows
Broadcast Shows
Daily News Shows
Special Shows
EVENTS
DAILY TIPS
Design
Mac OS X
Mac OS X UNIX
COMMUNITY
Surveys
NEWS
Current
Press
Archive
FEATURES
Editorial
Dr. Mac
Reviews
Reader Reports
RESOURCES
FAQ
Documentation
Learning Center
MAN pages
Glossary
Tutorials
Tips
Links

OUR PARTNERS

Tutorials 

Automating terminal commands using AppleScript.

by Dr. John Timmer, Contributing Editor

Burried in the excitement around the rapidly evolving capabilities of MacOS-X and the deserved praise given to AppleScript Studio, the good folks at Apple have quietly provided a revolutionary capability to their OS. Tucked into the 10.1.2 update was a new version of the Standard Scripting Additions, one which included the command "do shell script".

This may not seem revolutionary, but it opens up a world of possibilities. Users who would never touch the terminal could now run pre-compiled AppleScriptlets that let them tweak the Unix layer of OS-X. Those who are intimidated by the terminal may be less fearful of the friendlier interface of Script Editor. Others that may be able to run a shell script but don't know how to grep or write Perl scripts can now manipulate the output of Unix tasks with the friendlier AppleScript syntax. Perhaps most intriguingly, it opens up the possibility of integrating Unix programs with any application that responds to Apple Events, including Microsoft Office and Adobe Photoshop.

The downside is that not a lot of people know it's there or how to use it. In a small effort to correct that, I'll go through the basics of the "do shell script" command and, in a second section, we'll do two examples which should show you some of its capabilites.

The Do Shell Script Comand

If you open the Standard Scripting Additions dictionary and look over the "Do Shell Script" command, you'll see the following:

do shell script: execute a shell script or command
do shell script plain text -- the command or shell script to execute. Examples are ‘ls’ or ‘/bin/ps -auxwww’
[administrator privileges boolean] -- execute the command as the administrator
[password plain text] -- use this administrator password to avoid a password dialog
[Result: plain text] -- the command output

To translate, the basic syntax of the command is "do shell script "your command"", where your command is any unix command that you can type in the terminal. This will return, in plain text, whatever the command would print out in the terminal.

One of the catches here is that some Unix commands aren't in any of the places the underlying software knows to look. For this reason, it's often safest to include the full path to the Unix application you want. Fortunately, most Unix applications reside in a few specific locations - to find where the one you're interested in lives, you can check the following locations:

/bin
/sbin
/usr/bin
/usr/sbin
/usr/libexec
/usr/local/bin

So typically, the full path to a command would be something like "/usr/bin/whois". Many Unix applications also require flags to alter their behavior. So, to get all the details on the processes running on your computer, "/bin/ps" isn't going to cut it - instead, you want "/bin/ps -ax". Both the path and the flags need to be included in any command you send via AppleScript.

Doing the Root thing:

The "do shell script" command itself can also takes a couple of potential flags - these follow the command in quotes. Both are related to the ability of the command to be executed with root, or administrator privileges. The first flag determines whether to attempt to do so. The flag "administrator privileges" will always evaluate to "true", so if your script uses the format:

do shell script "/bin/ps -ax"

it will be executed as the user running it. Alternately, if it uses the form:

do shell script "/bin/ps -ax" with administrator privileges

it will be executed as root, provided the appropriate password is provided (more on passwords immediately below). This is critical, because some commands (such as kmodload/kmodunload) will only allow themselves to be executed by a root user.

Gaining administrator capability requires you to enter a valid password (the AppleScript runtime will provide this dialog for you without any extra code), but you probably don't want to re-enter the password for every command when you're executing a series of related ones. That's where the second flag comes in - the password variable. This can't be read or written to explicitly by the script; thus, you cannot save time by pre-setting your password with a command like:

set password to "myPass"

Instead, the AppleScript runtime saves the value for you the first time a valid password is entered within a script. Thus, after you executed:

do shell script "/bin/ps -ax" with administrator privileges

and entered the correct password, you could execute the next command within the script with root capabilities by changing the command slightly:

do shell script "/bin/kill -9 247" with administrator privileges and password

This will recycle the same password that was entered by the user when the script came across the previous command.

Getting feedback:

Lots of Unix commands are only useful because they output information - ps, the process list, is one of them. So, how do you capture this output? Simply by setting a variable to recieve the output from the "do shell script" function:

set myString to do shell script "/bin/ps -ax"

Now, the variable myString will contain the output from the process list.

I'll show you how to use this in the next part of the tutorial. One caution: do not ever execute AppleScripts (especially those which request a password) without knowing exactly what they are doing or having a great deal of trust in the script's author. These things can do serious damage to your files or System.

If you have any questions or comments about this article, feel free to e-mail me at john_timmer@osxfaq.com

Copyright © 2000-2010 Inside Mac Media, Inc. All rights reserved.
Apple assumes no responsibility with regard to the selection, performance, or use of the products or services. All understandings, agreements, or warranties, if any, take place directly between the vendors and prospective users.
Apple, the Apple logo, Mac, PowerMac G4, PowerMac G5, Xserve, Xserve RAID, PowerBook, iBook, Airport, AirPort Extreme, iMac, eMac, iLife, iMovie, iCal, iPhoto, iTunes, QuickTime, FireWire, iPod, iSight, AppleWorks, Macintosh, Jaguar, Panther, Mac OS, Mac OS X and Mac OS X Server are trademarks of Apple Computer, Inc.