AppleScript for System Admins WebCast

Justin Elliott writes "Watch Apple Computer's own AppleScript wizard, Sal Soghoian, present 'AppleScript For System Admins' during Mac OS X Labs' September 24 webcast. Learn about essential AppleScript tools and tips under Mac OS X. Discover how AppleScript can be used for administrative tasks, and how to use AppleScript to effectively interact with the Mac OS X file system."

Comments

Re:Don' Like AS

[skinfitz]

Good point - I remember on one of the admin lists some guy obviously from an OS9 background was having problems moving files around with Apple Script. I introduced him to shell scripting - turns out he had about 30 lines of code to essentially do some basic file copying and moving. I showed him he could do the same thing in about 3 lines of shell script.

You have to be careful with shell scripts on the Mac filing system though - you can end up losing the resource forks which breaks some files.

It rocks

[Anonymous Coward]

AppleScript rocks. It's a great way for users (that's users, not geeks) to automate stuff on a Mac. Its biggest power is probably the english-like language.
Like this iChat AV example:

tell application "iChat"
send video invitation to account "John Doe"
end tell

Not available until next week

[Corvus9]

Note that this site only contains connection information for a stream of a live presentation that will be performed on Sep. 24, 2003.

You can download the webcast software, but will not be able to connect or see anything until 1 PM EDT next wednesday.

Re:Don' Like AS

[Meowing]

Where are the shell scripts?

What did you want to do from the shell? Some programs are designed to be used from a command line in the Unix way, others are happier being controlled via the GUI and OSA [which you can still get to from the shell using open(1) and osascript(1)]. Those commands won't completely eliminate Applescript, but they will let you stick mostly to sh and only bring in OSA where the target program demands it.

AppleScript is hard to write

[Anonymous Coward]

AppleScript is like Perl's forgotten twin brother: Perl is fast to write and impossible to read, and AppleScript is highly readable but impossible to keep "in your head" .. too much like a weird dialect of english.

That being said it *rocks* for controlling GUI apps .. for instance you can generate diagrams in OmniGraffle diagramming tool entirely through scripts! I was trying to create a script to generate ERD from MySQL schema but gave up after a while because AppleScript is so chewy.

I like AppleScript, but...

[supton]

I wonder sometimes what Apple doesn't gradually dump AppleScript for Python? Think about it: it would give them a scripting platform as powerful as powerful as Java, but (nearly) as simple as AppleScript (perhaps more readable, and certainly more maintainable). Python 2.3 is going to get bundled with Panther, and is used in some core "essential functionality" in Panther and already has bindings to pretty much everything one would needs to tightly stitch to Apple's platform (ojbc, quartz, Java apps via JPE, etc).

Re:I like AppleScript, but...

[gerardrj]

Or for that matter, why not Perl. If you co scan CPAN you'll see Perl modules that will connect you in to most of the useful parts of OS X.

It's simple really: Apple prefers to do things in house where they have control. They don't have to fight with anyone or any standards body to revise or extent Applescript.

I can certainly see AppleScript going away in a few more revisions of the OS. With Project Builder so simple to use, Apple may just decide that actual binary programs are so easy to create that AppleScript is just no longer necessary.

Remember... Applescript was developed as a fast and easy way for people to manage small tasks without the drudgery of writing in C. In Project Builder you nary need a line of code, just drag, drop and fill in the blanks, thus eliminating the drugery.

Re:I like AppleScript, but...

[MalleusEBHC]

I wonder sometimes what Apple doesn't gradually dump AppleScript for Python?

Or why not just include both (as they will soon be doing) and give users more options to choose the right tool for the right job?

Re:I like AppleScript, but...

[scrotch]

Serious question:
Can Python (or Perl, or anything else) interact with other running OS X programs?

That's why we've used Applescript with OS 9 so much. We can write scripts that tell Quark XPress what to do. We can pull info from FileMaker and format it and place it in Quark auto-magicly. We've written scripts that manipulate text in Quark text boxes without ever leaving Quark - like they're just another menu item. We can do similar things with Outlook Express and BBEdit and any number of other apps. I've written a bunch of Applescripts, but very few that didn't interact with at least one commercial application.

Now if I can replace
FileMaker <- Applescript -> Quark
with
MySQL <- Python/Perl/etc -> Quark
that would seriously rock. Are you saying I can do that? Can you post a link to some info on getting started?

Re:I like AppleScript, but...

[henryhbk]

I suppose you could write a python action recorder, but it's a lot easier to use a language built around apple's event model for the record feature of applescript. This allowed non-coders to very quickly build a script to do something. And if it needed customization, it was a quick edit to change it. The lanugage is really for quick user actions or inter-application data sharing. For writing real apps, python is a better language, and certainly for sophisticated database interaction.

Re:I like AppleScript, but...

[SandSpider]

You don't really need to replace AppleScript with python, per se. The ability to call Apple Events is within the ability of many scripting languages on the Mac. You can also call AppleScripts from anything that can run a program via the command line, and you can send out command line tasks through Applescripts. It's a pretty useful technique to mix Applescripts with shell scripts based on their relative strength. And, yes, Applescript has the ability to do things easily in its language that other languages can't do as easily, and those things were designed to work well with the sort of tasks that mac scripters would need.

The main problem is that the dictionaries for the various applications's Apple Events are geared towards Applescript (if, indeed, they are geared towards anything at all. Most dictionaries thoroughly suck). If you want to make the calls from another language, you kind of have to figure out how the event calls work, but that's not a significantly more difficult task than in AppleScript, for reasons labelled above.

The trickiest thing to do in Python instead of AppleScript would be making a Cocoa Application with it. AppleScript has AppleScript Studio, which will let you make a full, ableit slow, Cocoa Application, with logic being done in Applescript. You can include and call Objective C and Java Methods from these scripts, so if you wanted to use existing code and/or optimize some often run code, you could do that without too much trouble. It also gives you access to the entire OS framework within AppleScript, so you could make Rendezvous aware services without having to know much about Objective-C. I suspect you could use Python or Perl this way, but it might be some work getting it set up.

From a practical perspective, I like to use whatever is handiest at the time. So, for example, if you needed to get a list of files from a web site, you could easily do

set theString to do shell script "curl -l -s ftp://username:password@someftp.com/ | grep 'unique identifier string'"

That could just as easily have been a one-line perl script or even a call to a script. The trickiest about passing generic scripts as a text block is making sure the text is quoted properly, but I'll leave that as an exercise to the reader.

As far as going the other way around, and calling apple events from a shell script, I forget how to do this. There are libraries for Perl and Python that will let you do it, and you just use those functions or methods to call the Apple Events and pass the proper parameters. Here's an example for MacPerl. In any case, Google is a good tool for finding that sort of information.

=Brian

Re:I like AppleScript, but...

[bill_mcgonigle]

Now if I can replace
FileMaker <- Applescript -> Quark
with
MySQL <- Python/Perl/etc -> Quark
that would seriously rock. Are you saying I can do that? Can you post a link to some info on getting started?

The stuff in the middle of your diagrams can be any OSA scripting language - it just so happens that AppleScript is the only one with any momentum behind it. Frontier used to be possible. When I get a MacArthur grant, I'll write the perl pieces.

In the meantime, if I had to bet, I'd say Ruby is the most likely sucessor to AppleScript. Maybe OSX 10.5 will support it directly.

Re:I like AppleScript, but...

[nullard]

I wonder sometimes what Apple doesn't gradually dump AppleScript for Python?

Anyone who wants another scripting language instead of AppleScript can do it themselves. AppleScript is not a one man show, it is part of Apple's open scripting architecture.

Anyway, a google search reveals this: Using the Open Scripting Architecture from Python

Re:watch in dismay...

[shpoffo]

luckily it is a week from now - which is longer than the whimsical 'just curious' attention span (I attribute) to most ./'ers

-shpoffo

Re:Don' Like AS

[L_Saint]

I think when it comes to automating applications AppleScript is more powerful than people realize. However when it comes to system scripting, shell and perl scripts are still the way to go. I recently wrote a login script that I prototyped as a shell script and then wrote out as an AppleScript. I ended up using the shell script. Much smaller and easier to write. Simple commands like echo and grep take many, many lines of code in AppleScript. Even complicated tools like awk are still easier to write out than the equivalent AS code. As I become more familiar with perl and python, those might even be a better way to do system scripting.

You can manipulate files with resource forks in the shell using the MacCp, MacMv, and ditto commands which will preserve the resource forks.

inter-application and inter-script glue

[hayne]

Now if I can replace
FileMaker Quark
with
MySQL Quark
that would seriously rock.

You can call AppleScript from other scripting languages (Python/Perl/Bash, etc) and call other scripting languages from AppleScript, so you can do each manipulation in whatever language you find most convenient. I usually find it easiest if you keep AppleScript for manipulating objects within your application (Quark) and do the backend data manipulation in Perl etc.

Apple has a page about using 'do shell script' to invoke UNIX scripts from AppleScript

To go in the reverse direction, you invoke the AppleScript using /usr/bin/osascript as in this snippet of Perl code:

# runAppleScript: Runs the supplied AppleScript
# The argument is the text of the AppleScript.
sub runAppleScript($)
{
my ($ascript) = @_;

my $result = `/usr/bin/osascript<<" EOT"
$ascript
EOT
`;
chomp($result);
return $result;
}

# getTextOfFrontWebPage: Gets the text of the frontmost web page from Safari
sub getTextOfFrontWebPage()
{
my $ascript =<<" EOT";
tell application "Safari"
text of document 1
end tell
EOT
my $text = runAppleScript($ascript);
return $text;
}