Volume Number: 15 (1999)
Issue Number: 8
Column Tag: Network Administration

AppleScript for Network Administrators

by Russ Coffman
Edited by Todd Staufer, Technical Edit by Cal Simone

Getting Started

You may have programmed in BASIC, HyperCard, or C, or not at all. I had done all that plus used UserLand's Frontier scripting system, but for some reason, I was slow to get into AppleScript. Now I can't stop. If you have thought of getting into AppleScripting but haven't yet, here are some reasons and ways to get started, especially if you are a network administrator.

Like anything, motivation is important in learning. It helps to have a particular problem in mind before starting. But that requires knowing what AppleScript can do. That turns out to be a lot. For a quick start on its capabilities, visit Apple's AppleScript web page at http://www.apple.com/applescript/

Luckily, there are almost limitless applications for network administrators within the scope of AppleScript. Here are a few simple ones I found when starting off:

• Simple but tedious tasks. An early script I wrote just deleted the contents of folders on file servers used for backups. Users would drag files to be backed up to their backup folder, but that tended to fill up the server (since replaced with G3s). Opening each folder, selecting all the items in the folder, and dragging them to the Trash was tedious. AppleScript can process all folders in one drag and drop. This was a simple script, but did the job.
• Repetitive tasks. Another simple script opened 1800 WordPerfect documents and saved them as plain text files for input into an archiving and indexing system. Sounds easy, but getting footnotes out too required some tricks. Several days of manual labor was done in a few hours, error-free.
• Cleaning up after an install, or doing complete installs. A lot of software can be safely drag-installed -usually faster than running an installer, plus you can make new aliases in the Apple menu, save and restore user files to the right place, and in general customize the installation to your users' needs. System installs often install unneeded files - use scripts to keep your System Folders lean and clean.
• Periodic operations. Examples are backing up an important file or folder, or watching for some network condition and being alerted to it. We had a problem with our 4-Sight fax server application dying. Luckily it was scriptable (but the documentation and scripting addition are hidden on one of the install disks), and had a command that would just say "I'm here." A stay-open applet (a script application that doesn't quit after executing) polls it periodically and alerts me if it does not get a response.

Get Motivated to Learn AppleScript

Those are some general uses for AppleScript, well within its capabilities, and good learning exercises. Think of your shop and identify potential applications. Start with at least one real problem and keep it in mind as you learn: this will be Your First Script.

Now, how do you go about learning AppleScript? Learning AppleScript is much like learning to play the trombone. The best way to learn the trombone is to play the trombone. The best way to learn AppleScript is to write scripts! But there's still the "getting started" thing. You've got your real world problem defined - a big step. Solve that problem and you've got some positive feedback - "I can do this!" From then on, you'll never want to stop AppleScripting. The upside is that AppleScripting is much less annoying to others than playing the trombone. It might even get you a raise, or even a new career. It certainly looks good on your résumé.

Getting Started

You don't need much to get started. Apple's Script Editor is included with every Mac. If you plan to get gung-ho with AppleScript, you may want to invest early on in an editor/debugger, such as Main Event's Scripter®, or Late Night Software's Script Debugger. Both of these tools let you step through scripts one command at a time, see the result of each command, watch variables change, and much more. You need two more things to get started: a good book and a good learning environment.

Get a book (or better, several books) on AppleScript. Like many people, I started with Danny Goodman's AppleScript Handbook, now in print again, but somewhat out of date. No matter, it's a good intro. See the list of reference material at the end of this article for more good books. Whichever book you choose, be determined to start at page one and work to the end, skipping nothing.

Do all the examples and exercises. It's important to type in the examples, don't just load them from a disk if one is provided. The exercise of typing in a script makes you think through what you are doing. Soon you'll notice you can anticipate what's next without even looking at the next line - you'll go into "auto-complete" mode! Trust me on this, it works. Just watch for for that "I can do this" light bulb to light up above your now-swelled head.

People learn best in different ways. You may do best by setting aside an hour a day with a goal of getting through one chapter or one exercise in that hour. Others, like me, do best with total immersion - at least four uninterrupted hours of study with no distractions. Have an AppleScript Weekend. Decide on a regimen that has worked for you and stick to it. Have plenty of water, coffee, Jolt Cola, and snacks available. You want to be way up on Maslow's Pyramid so you can concentrate on AppleScript. Set the mood to what works for you, from total silence to MTV.

Now let's look at a few scripts. Even if you are new to AppleScript, you'll find it literal enough to follow along. To help, in the scripts below I've added "comments," indicated by a double dash:

- my comment blah blah.

First, let's look at deleting the contents of folders dropped on an AppleScript droplet (As mentioned, an "applet" is a script saved as an application that acts like a real application. The script can run when double-clicked and it can receive and handle messages sent from other applications and scripts. It can also process items dropped on its icon in the Finder - if so, it's a "droplet"):

on open fileList
-sets the variable fileList to a list of folders dropped

Any AppleScript applet becomes "droppable" in the Finder just by including an "on open" handler (a handler in AppleScript is the equivalent of a procedure, function, or subroutine in other languages - a starting point for a block of commands). In AppleScript, a handler can respond to a message from another application, in this case, the "open" handler responds to "open" messages sent from the Finder. A list of references to files, folders, or disks you drop are passed to a variable, in this case fileList. A list in AppleScript is a one-dimensional array of the form {item 1, item 2...item n}, where the items can be any type of object - text, numbers, references to files, even other lists. The "lazy L" character ¬ (type Option-L) is a command continuation character that lets you break up long lines for better readability.

Next, since we're talking about deleting files, let's ask if we really want do to this:

  display dialog ¬
    "Do you really want to delete the files in the 
      selected folders?" ¬
    buttons {"Delete Files", "Quit"} default button 
      2 with icon stop
  if the button returned of the result = "Quit" then return
-quit, doing nothing

Otherwise, let's process the folders. The application that deletes files is the Finder, so we want to tell the Finder to do the work. The script does just that with a "tell" command. All statements between the "tell..." and "end tell" commands are directed to the application named in the "tell" command:

  tell application "Finder"
-next commands "talk" to the Finder

AppleScript has a special form of the repeat loop that processes items in lists in sequence - a handy and often-used feature. Each time though the loop, the variable myFolder will be set to the next item in the loop until the last item is processed:

    repeat with myFolder in fileList
-sets myFolder to each folder in the filelist
      delete every item in myFolder
-use of "every" saves using an inner loop
    end repeat
  end tell
end open

Now let's take a look at a quick script for automating a drag-install. This is a great one for labs, retail computer stores and other situations where you might, after a while, get sick of manually installing files that get moved by users. This script replaces just the application named "Premise" in its folder, assuming other items do not need updating:

tell application "Finder" activate  if the disk ¬
  "Old Bailey" exists then
-is the server containing the file up? 

First, a sanity check - is everything in the right place? Then, copy the file, replacing the old file without asking first.

if the folder "West Group Research" of the folder ¬ 
"Applications" of the startup disk exists then
    duplicate the file ¬
"Old Bailey:Premise Install:West Group Research:PREMISE"¬
  to the folder "West Group Research" of the folder ¬
  "Applications" of the startup disk with replacing

Delete the old alias in the Apple menu, using a construct that will find the alias we want even if the user has added a leading character to change the sort order - a common occurrence. That's the kind of real world stuff you'll learn to write scripts for. Finish up by making a new alias:

      delete (every file of the apple menu items folder ¬
        of the startup disk whose name contains "Premise")
      - pretty literal, huh?
      make new alias file at the apple menu items folder ¬
        to the file "Premise" of the folder ¬
        "West Group Research" of the folder ¬
        "Applications" of the startup disk
    else
      -- the target folder probably moved
      display dialog "Can't find Premise folder." ¬
      buttons "Quit" default button 1 with icon stop
      return
        -quits and closes the script
    end if
  else
    -couldn't find the file server
    display dialog "Old Bailey not mounted." buttons "Quit" ¬
default button 1 with icon stop
    return
  end if
    -quits and closes the script
end tell
beep
-we're done

That was easy, wasn't it? A more elaborate script does an install of all files required if a complete update or first-time install is needed. I use this premise for the basis of a more elaborate script in my work, which does a number of things. My more elaborate version:

1. Moves any non-standard (user) files in Premise's folder to the Desktop.
2. Replaces the entire Premise folder.
3. Deletes old preferences and adds new Preferences Folder items.
4. Restores user items to the new application folder from the Desktop.
5. Makes a new alias in the Desktop menu after deleting any existing alias.
6. Adds one extension and deletes the old version if present.

And it does all this in a fraction of the time it takes to use the installer, all with just a double-click. Whew! (Sometimes it's good to hire lazy people because they'll find an easier way of doing things. But don't quote me on that.)

A Periodic Script

Now for a periodic script, one that stays open, once launched, and performs a task periodically. The key here is the idle handler. The "idle" message is sent to a script application by the system at an interval you can specify:

-bring the Finder to the front after launch to be user-friendly:
tell application "Finder" to activate
-we start here each time the system sends us the idle message:
on idle

Parts of the next command (the Network Address and Pick Server commands) come from an AppleScript scripting addition - a file that adds additional commands to AppleScript's repertoire (more on scripting additions later). This one came with 4-Sight Fax, and lets us check to see if the fax server application is alive:

  set z to Network Address of  ¬ 
    (Pick Server using "Pony Express" without picker)
  if z is 0 then
    -if a zero is returned, the server isn't up
    beep
    activate
      -bring this script to the front
    display dialog "Fax server is down!" buttons ¬
    {"OK", "Try Again"} default button 2 with icon caution

The Pick Server command tends to gets a lot of false alarms - the server is not down, just busy when we called, so we'll wait a second and try again. Notice you can determine what button was pushed and take different paths of action:

    if the button returned of the result is "Try Again" then
      -try again, obviously
      set z to the Network Address of¬
        (Pick Server using "Pony Express" without picker)
      if z is 0 then
        display dialog "2nd check: Fax server is down!" ¬
        buttons {"OK"} default button 1 with icon caution
      end if
    end if
  end if
  return 60
  -the "60" tells the system to send the idle message again in 60 seconds 
  -this saves a lot of CPU time
end idle

This simple, easy technique can be used to check for almost any condition and alert you if necessary. Most email applications are scriptable these days, and there are even pager systems available, so you could elect to be notified by those methods as well.

In that last example, we had to use a new command that came from an AppleScript scripting addition. One amazing feature of AppleScript is its extensibility through the scripting addition, also known as an OSAX (Open Scripting Architecture eXtension; plural form: OSAXen). Apple includes some, but there are hundreds of freeware, shareware, and commercial scripting additions available. These add functionality such as list and text manipulation, higher math, better dialogs and other users interface features, and too many other commands to even begin to list. Start collecting and reviewing these -they can be big timesavers.

That said, heed this warning: Don't just install every scripting addition you can get your hands on. Eventually you will run into "terminology conflicts" where the terminology of a scripting addition will conflict with that of an application or another scripting addition. (More on terminologies below.)

Of particular interest to network administrators is Akua Sweets, available on the Info-Mac HyperArchive. With this scripting addition, you can gather network information, more easily control remote machines, display text information, create windows with drawn graphics, play movies, massage text, manipulate file resources (careful!), and do dozens of other handy things you'd normally need an application to do.

So how do we find out what's in a scripting addition, or in a scriptable application? In Apple's Script Editor, choose Open Dictionary... from the File menu, then open the scripting addition or the scriptable application. Lo and behold, everything that scripting addition or application file can do in AppleScript is displayed! What you are looking at is the dictionary window, which shows the scripting addition's or application's terminology - the words and phrases that application provides as its extensions to the AppleScript language. Dictionaries can be hard to understand, though, and to make things worse, they may be the only documentation you have. They will become clearer as you learn AppleScript, fortunately, but perhaps only after considerable trial and error. (It's worth noting that Scripter has "builder" windows that allow you to point and click on words and phrases in the terminology to help assemble the commands.)Also in the last example, notice you had a moving target - the fax server hardly ever goes down just so you can test your script. Here's where a debugger and a simple trick can be a big help: You could put in a dummy command representing the two possible conditions, each in turn, then step through your script to see if it takes the path you expected. This is called "exercising your script" - actually executing every line at one time or another to be sure it works as expected.

For example, instead of:

  set z to the Network Address of
    (Pick Server using "Pony Express" without picker)

substitute

  set z to 0

then

  set z to 1

to "exercise" both possible paths in the debugger. It beats crashing the fax server just to test your script. If you can easily control the condition you're testing for, such as the existence of a file or folder, then change the condition and step through the script again for an even better test.

Other Solutions (for Motivational Purposes)

• Enter a lawyer's special task with a due date in FileMaker. From within FileMaker, the lawyer(s) is sent email with details, and date of origin and due date events are created in Now Up-To-Date so management can see the big picture at a glance. Reminders are sent every three days until completed.
• All users can query the case log database via a FaceSpan application. Features hot help, printing, and copying results to the Clipboard.
• Premise also has a bad habit of forgetting where the shared Library folder is if you start it without the file server mounted (a common occurrence despite many warnings to users). A "Rescue Books" script makes a backup copy of the Library folder's alias created by Premise, and restores it again if lost. This is great if I'm not there to make the rather complicated fix. A similar script, "Rescue WP," backs up and restores WordPerfect's preferences, which often get corrupted, causing a crash on launch.
• Forward QuickMail messages and attachments to an Internet account via Outlook Express. Inserts list of attachments and what program created them into the message body.
• Install or upgrade QuickMail and 4-sight Fax, deleting old files and aliases, and creating new aliases. Faster and cleaner than using installers.
• One step drag and drop sending of files from home to office and vice versa.
• In progress: a network In/Out board.

The other aspect of extensibility, in addition to scripting extensions, is scriptable applications. FileMaker Pro, the leading database on the Mac, is perhaps the best example of this (well, QuarkExpress has the larger AppleScript dictionary, but FileMaker is of more interest to network administrators). There is enough in some applications' dictionaries to keep you occupied for a long time. Seriously, you may well have to prioritize your scripting efforts - either that, or hire an assistant to fix machines while you script (my secret master plan).

One gotcha: You may not find a word about AppleScript in the application's manual. Other than its AppleScript dictionary, FileMaker's only documentation is in a document optionally installed. No documentation is available for Microsoft Outlook Express beyond its dictionary (I asked) - you'll have to join the Outlook Express mailing list or visit The Unofficial Microsoft Outlook Express Page (see info at the end of this article) for more information and sample scripts.

Scripts that just copy or delete files don't require much of a user interface, if any. Beyond the very simple alert dialog shown above, AppleScript offers nothing in the way of user interface. If you want to display data and offer execution options via buttons and menus, there is one magic name to remember: FaceSpan.

If you have an existing script, you can literally throw together a FaceSpan project in a few minutes. Just make a window, add a button, attach your script to the button, and display the result (or results) in a "text box." A number of other window objects are available: scrolling list boxes, tables (similar to a spreadsheet), text labels, pushbuttons, radio buttons, scroll bars, various types of slider controls, tabbed windows, reveal ("twirly") arrows, lines, rectangles, picture boxes, and even QuickTime movie boxes. Any object can have a script attached that runs when the object is clicked. The appearance and behavior options for each object type are extensive.

FaceSpan will likely keep you up nights just playing with all its options. Unfortunately, it's a little beyond the scope of this article, but it's a "must have" - right after your debugger. I urge you to get the free demo and manual and take a look.

Grad School: Taming a Problematic Application

Of all the software you have running on your network, one has to be the worst. For me, that one is Premise, West Group's CD-ROM-based application for legal research. Usually you just stick in the CD-ROM you need at your own workstation, but we copied all the CD-ROMs - 36 in all - to three 4-gig hard drives and hung them on a file server. Now any user on our network can use any CD-ROM, with one restriction: West's fiendish licensing scheme.

In a shared "Library" folder, Premise manages the number of users of each "book" (the CD-ROMs roughly parallel real law books). After two years, I finally discovered that sometimes the main license-tracking file, LICENSE.LIC in the Library folder, doubled in size periodically, sometimes several times a week. As it grows, Premise takes longer and longer to open and close books (or just crashes) - and we have a lot of glacial Duo 230s. I needed to be alerted when the file grew. This turned out to be a fairly simple, but extremely important "breakthrough" script. Saved as a stay-open applet, it checks LICENSE.LIC's size every 30 seconds. The script was similar to the one above that checks to see if the fax server is up, and was later dropped in to a new FaceSpan mini-app with only minor mods.

But while I was under the hood, I decided it would be a good idea to log the increase for use by sympathetic but stumped West Tech Support people and added that feature later. With the log, we hope to determine what circumstances cause the file size to double. Lastly, I needed to know how many users actually have a book open because I can't add book updates while they do. That is determined by the number of files that end in ".tmp" in the Library folder. Checking the license size and for the existence of .tmp files can easily be rolled into the same script, and displayed in the same FaceSpan window. The size-checking commands were reused so that the LICENSE.LIC file size and count of .tmp files are done each pass.

property licSize : 0
  -remembers last licSize between launches
global didBeep
on run
  -initialize
  set didBeep to true
  -not shown: other FaceSpan initialization commands
end run
on idle
  -called when nothing else is happening
  tell application "Finder"
    if the disk "Old Bailey" exists then
      set newSize to (the size of the file ¬
        "Old Bailey:Library:LICENSE:LICENSE.LIC")
      set numTemps to the count of (every item of alias ¬
         "Old Bailey:Library:LICENSE" ¬
        whose name ends with ".tmp")
    end if
  end tell
  if newSize != licSize then 
  -aha, the size has changed, alert the media
    beep

Using the concatenate operator, "&," we can build up a meaningful message for our alert dialog:

    display dialog "New size: " & (newSize as integer) ¬
     & return & "Old size: " & (licSize as integer) ¬
    & return & "Diff: " & ((newSize - licSize) ¬
    as integer) with icon note buttons "OK" default button 1
    set myFile to my OpenFileIfItExists ¬ 
      ("Data:License Info", true)
      -OpenFileIfItExists handler opens the output file (handler not shown)
    if myFile < 0 then
      - we got an error
      display dialog the result
    else
      -write date/time and new size to text file
      set myInfo to (((the current date) as text) & " " & ¬
      (newSize as integer) as text) & return
      write myInfo starting at eof to myFile
        -eof is "end of file"
      close access myFile
        -all done writing to log file
    end if

    set licSize to newSize
     -remember changed file size
  end if
  

Update the FaceSpan window's text items and use text to speech to alert you when there are no users with open books:

  set label "licSize" of window "Main" to licSize
  set label "numUsers" of window "Main" to numTemps
  if numTemps = 0 then -no users with open books
    if not didBeep then -only speak first time through
      say "Zero Premise users." using voice "Zarvox"
      set didBeep to true -remember I've "beeped"
    end if
  else
    set didBeep to false
  end if
  return 30
    -"sleep" for 30 seconds
end idle

More problems: Some books have only a single-user license, and some users go to lunch with a book open, preventing others from using it, just as with a real book. Apple Network Administrator's Toolkit lets you see what application is frontmost, but what if Premise is not frontmost, and you have 70+ lawyers and legal assistants, some in a different building blocks away, and you need to find the offender? You guessed it, AppleScript! I wrote a FaceSpan mini-app that "knows" who uses Premise (no need to check other users).

Using the Akua Sweets scripting addition, I get a list of who's online, then check each Premise user to see if Premise is in the list of open processes running on that user's computer, and display the results in a simple FaceSpan window. Note: This requires that program linking be turned on and that user "Guest" allows program linking, but otherwise requires no additional software on the target machines. You could write a small stay-open applet and ask it to gather and return the information (tends to be slightly faster), but the goal here was to be as unintrusive as possible, by eliminating the need to have an extra application running.

on hilited theObj -clicked button "Find users of:"
  -get name of app to search for from a popup menu:
  set appToFind to the contents of the selection of the popup "appToFind"
  set userList to the storage item "userList" -list stored in FaceSpan object
  set premiseUsers to ""
  set numUsers to 0
  set label "numUsers" to "0"
  set listbox "allUsers" to "***"

This mini-app depends heavily on the Akua Sweets scripting addition. First, we use the network server names command to get a list of users online (remember we turn on program linking on target machines, this makes them show up here). This happens quite fast. We only check users in this list, since looking for an offline machine name takes a while to time out, and we only check machines in the list of Premise users, not every machine on the network. Using both lists drastically cuts down the time required to finish the search.

  -use Akua Sweets OSAX to get a list of users online:
  set allUsers to item 2 of item 1 of (the network server names)
  -goes very fast, saves time later by not looking for users    not online
  set countUsers to the count of items in userList
  set label "countUsers" to countUsers
  -set up progress bar:
  set the minimum of gauge "progress" to 0
  set the maximum of gauge "progress" to countUsers
  set the leap of gauge "progress" to 1
  set the visible of gauge "progress" to true -show progress    bar during scan
  set n to 0
  idle -lets FaceSpan update window
  repeat with theUser in userList
    set n to n + 1
    set the scroll of gauge "progress" to n -advance progress bar
    -save time by only checking users who use Premise:
    if theUser is in allUsers then
    if command down then return -bail out if command key is down
      set label "Status" to "NET"
      set listbox "apps" to {"***"}
      set textbox "User" to theUser
      set x to {} -initialize list of apps in use
      idle -lets window "Main" changes update
      set found to true
      with timeout of 10 seconds

Use talk as user "" on server theUser to "talk" to each machine in turn. Without this command, a "connect to..." dialog would come up for each user - impractical for a large number of users. Note that user "" (empty string) is shorthand for Guest.

Note that the "raw" AppleEvent class, «class prcs», is needed in place of "process" to compile when the machine name is a variable:

  -another Akua Sweets command bypasses the "connect to" dialog:
  talk as user "" on server theUser -"" means logon as guest
        tell application "Finder" of machine theUser
          try
            set x to the name of every process
            -returns list of apps
            -on mixed 7.6.1 and 8.x systems, use instead:
            -set x to the name of every «class prcs»
          on error
          end try -just ignore any errors
        end tell
      end timeout
      -if list of apps is empty, didn't find, or was error
      set found to x != {}
      if not found then
        set label "Status" to "OFF"
        idle
      else -found user
        set label "Status" to "LOC"
        idle -draw label "status"
        tell application "Finder" of machine theUser        try
  -again, «class prcs» is needed for mixed system versions:
        set y to ( the name of the first «class prcs» 
            whose frontmost is true)
          on error errMsg number errNum
            tell me to idle
            set y to "Finder"
          end try -just ignore any errors
        end tell
        if appToFind is in x then -build list of users
          set premiseUsers to premiseUsers & theUser & return
          set listbox "allUsers" to premiseUsers
          set numUsers to numUsers + 1
          set label "numUsers" to numUsers
          idle -draw listbox "allUsers"
        end if
        -Label frontmost app with * character
        repeat with i from 1 to count of x
          if item i of x = y then
            set item i of x to item i of x & "  *"
            exit repeat
          end if
        end repeat
        set listbox "Apps" to x
        idle
      end if -found
    end if -user online
  end repeat
  set the visible of gauge "progress" to false
    -hide progress bar
end hilited

With the list of possible offenders displayed, a phone call or two gets the books closed. A few more lines of script and you could get other information, such as free RAM and disk space.

Now my monster is more under control. I can track the file that causes crashes and slowdowns, tell when it's safe to update the library, and find errant users. You can use the same ideas to keep up to date on what's happening on your network.

[optional] What's next? Prescience. A giant script, or, more likely, a set of interactive scripts, that hunts down and fixes problems without human intervention and sends me a report once a month. Toss a few files in a folder on a server somewhere and all machines get updated to the latest stuff and an explanatory email gets sent to affected users. Status windows on a Mac with a bank of three or four monitors show what's up at a glance. Why not? Technically, you could come close to that today.

A Few Random Thoughts

A script doesn't have to be elegant, long, or complex. It just has to do the job. Start simple, and save every command - you'll find you can reuse a lot. If your scripts are to be used by others, build in more robust error checking and experiment with FaceSpan. If the script is just for you, I say just go for it. You can understand AppleScript's error messages, users can't.

Steal as much as possible from others, but understand how it works. Hail the day your new script compiles and runs the first time without error. You have arrived. By the way, don't forget to comment your scripts (unlike me).

Network administrators will find many, many uses for AppleScript once the scripting begins. If you have put off looking at AppleScript, I hope I have given you a few reasons to take that first step.

More Information

• AppleScript home page: http://www.apple.com/applescript/

• AppleScript Handbook by Danny Goodman, ISBN 0966551419, http://www.dannyg.com/
• AppleScript for Dummies by Tom Trinko, IDG Books, ISBN 1568849753
• The Tao of AppleScript by Derrick Schneider, Hayden Books

• Applescript Applications: Building Applications With Facespan and Applescript by John Schettino, Liz O'Hara, ISBN 0126239576
• AppleScript for the Internet: Visual QuickStart Guide by Ethan Wilde, ISBN 0201353598

• The MacScripting Mailing List (Dartmouth) http://www.dartmouth.edu/info/macscript/mailing-list.html
• AppleScript-Users (Apple) http://lists.apple.com/lists.taf

• Scripter by Main Event Software http://www.mainevent.com/
• Script Debugger by Late Night Software http://www.latenightsw.com/
• FaceSpan by Digital Technology International http://www.facespan.com/

• Info-Mac HyperArchive http://hyperarchive.lcs.mit.edu/HyperArchive/HyperArchive.html
• Scriptweb http://www.scriptweb.com/

• The AppleScript Sourcebook http://www.AppleScriptSourcebook.com/
• AppleScripter.com http://www.applescripter.com/
• The Unofficial Microsoft Outlook Express Page http://www.macemail.com/oe/index.shtml

Russ Coffman has been a Mac user since 1984, a Mac consultant since 1985. Today he is the network administrator in the Dallas City Attorney’s Office, an all-Mac law office with 115 users. He has used AppleScript to develop numerous utilities as well as “wire together” various scriptable applications.