|
Tutorials 
Automating terminal commands using AppleScript - Part 2.
by Dr. John Timmer, Contributing Editor
In the previous section, I gave an overview of how to execute Unix shell commands without ever leaving AppleScript. In the second part, I'll provide some concrete examples of how to get useful work done with AppleScript's shell capabilites.
In a previous tutorial, I showed you how to set up an OS-X machine to route a PPP connection. Now, I'll show you how to automate that process, which requires three commands, all executed as root:
sysctl -w net.inet.ip.forwarding=1
natd -interface ppp0
ipfw add divert natd ip from any to any via ppp0
all with root access. In order to do this with AppleScript, we simply have to encapsulate the commands in the "do shell script" function, and give them privileges. In order to save time when the script executes, we'll only authenticate with a password once and then recycle that password for the remaining commands. In the script, we'd do:
do shell script "/usr/sbin/sysctl -w net.inet.ip.forwarding=1" with administrator privileges
do shell script "/usr/sbin/natd -interface ppp0" with administrator privileges and password
do shell script "/sbin/ipfw add divert natd ip from any to any via ppp0" with administrator privileges and password
Execute that in a script, and your machine becomes an internet router. Save the script as an application, and you can run it any time you want to start routing.
That was nothing more than pushing simple commands that could easily be made into a typical Unix shell script. For the next example, we'll do something with the output from a Unix command - we'll use ps to get a list of running processes, then pick one of them out and kill it. A typical line of output from ps looks like:
8937 ?? Ss 68:52.58 /System/Library/CoreServices/WindowServer console
Where the first item is a process ID, and the 5th is the path to the application. In addition to a header, ps outputs one such line for each of the processes running on your machine. Fortunately, AppleScript's text handling capabilities are excellent, and we can use them to identify the process ID of a specific process we'd like to terminate - for example, the Dock (and who hasn't wanted to kill the Dock at one point or another?). A script to do this would look like:
set myString to do shell script "/bin/ps -ax"
set theCount to the number of paragraphs in myString
set loopCounter to 1
repeat theCount times
if paragraph loopCounter of myString contains "Dock.app" then
set psNumber to the first word of paragraphs loopCounter of myString
set theCommand to "/bin/kill -9 " & psNumber
do shell script theCommand
return
end if
set loopCounter to loopCounter + 1
end repeat
We can focus in on a couple of critical lines. In order to do anything with the process list generated by ps, we have to capture it. We do this 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. The repeat loop then goes through the result a line at a time, using AppleScript's ability to interpret each line as a paragraph. When it finds a line that contains "Dock.app", it looks for the process number on that line, and appends it to the kill command.
set psNumber to the first word of paragraphs loopCounter of myString
set theCommand to "/bin/kill -9 " & psNumber
When the command is executed with "do shell script", the dock dies.
This should give you some idea of just how powerful the "do shell script" command can be, especially when combined with the text processing capabilities of AppleScript. Things get even more impressive when you begin to consider some of AppleScript's other abilities, such as the scriptability of many of the programs already present on your Mac and the ability to generate full GUI based scripts using AppleScript Studio.
One again, a 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.
| 
