And now presenting under the topic of scripting for system administrators, AppleScript, Shell, Perl, etc. John Rennich. We actually have some people here. That's exciting. We had to compete with the Apple Remote Desktop session, so nobody get up and leave because I said that. And it's Friday afternoon. So scripting for system administrators. When they asked me to do this, they had a huge amount of stuff that they wanted included in one session. They said, AppleScript, Shell, and Perl. I said, you know, that's an awful lot of stuff to get done in an hour.

So I don't pretend that I'm going to be able to teach you everything you need to know about AppleScript, Shell, and Perl in 60 minutes or less. However, hopefully I can give you enough good examples of fun, exciting, very interesting things that I have done with these and that you can also easily do with them. I'll primarily be concentrating as we go through on the number of interactions that you can have between one or the other.

Just because you have a favorite language doesn't mean that you're eliminated from using the other language for doing the other things. And so certainly the deficiencies of one language can easily be overcome by the advantages of another language. So that's what I'll be concentrating a lot on. Got a lot of example scripts. Those will all be available on my website.

AFP548.com is the website if you don't know that. If you don't know what that reference is, that's fine. Look on the website. You can become a better geek. So all these example scripts will be available that you can download, take a look at. Hopefully you can increase your own code with it.

So without further ado, AppleScript, Shell, and Perl, why you want a script, and some examples. Because a lot of people that I'm-- I find a lot of bit when I'm consulting and when I'm training that I tell people, "Well, that's easy. That's three lines of shell." "Well, but I don't want to have to learn shell." "Well, then that's four lines of AppleScript." "Well, I don't want to have to learn AppleScript." "Well, that's a couple lines of Perl." Well, it really isn't that big of an impediment to getting something done that you want to do.

How many are currently scripting? Great. So I can get rid of that whole argument right there. We don't need to convince you that you need to do that. All right. So some ideas about when to write a script, some ideas about what language to write it in, and some really cool script ideas, because that's what we're all here to learn how to do the sexy, fun stuff to make our lives a lot easier.

Three major scripting languages we'll be talking about. The Camel for Perl, the AppleScript, and the Terminal for Shell. You'll see those as we go through here. Sometimes it's a hard sell why you want to do a script. Sometimes you need to convince yourself. Sometimes you need to convince your boss. Sometimes you need to convince someone else why you want a script.

These are a couple good reasons why you want a script. It's easy. You can liberate admins, right? I think I used to have something in there about how a script was a lot less expensive than an admin, but they got mad at me for that because admins might take offense, and we don't want to put people out of work. Your fingers definitely can get tired, but if you have a script, you never have to do it again. If you ever know you're going to have to do it again, script it.

It's so much more fun to write a script than it is to continually do the same thing over and over and over again. That shouldn't be a hard thing to have to understand. No matter how old you are, you're too old to understand. You're too old to do the same thing 15 times in a row. There's just no reason to have that level of repetition in your administration workflow. Definitely others need to be able to do it. Reliability.

A script never gets things wrong once the script has been written right. It's not going to mistype something as it goes in there. My biggest problem, typing is bad. Tab completion works great for me, but it can't do everything, so a script takes care of the rest of that.

It's certainly a lot more fun to write a script than it is to close out a trouble ticket. If you can get a script to close that out, and you can just use ARD or something else to push that out, then you can solve some problems easily that way. I came up with a little chart. Amount of work accomplished by amount of admins. Oh, man. We missed the actual. The yellow line on top is admins who script.

The red line is admins who don't. That lost in graphics, but that's okay. It's exciting, right? The more scripting you do, the more efficient you are. Then I gave that, and they said, well, I can't really use those numbers, because they weren't scientific, and we didn't want people to think that I had done an actual study on this.

These are fake numbers, but you get the idea that if you start out as an admin that's scripting, you've already got work that's being done for you without you having to lift a finger. Definitely, scripting is a very good way to go. When to script. There's times that you should script, and there's times that you shouldn't script.

When you need to automate the process, when you need to make sure it's done the same way every time, and when you find scripting more fun than real work. All great times to script. I certainly don't want to encourage anyone to do work when scripting calls. If you have the need, if you have that desire, and you find it fun, go start writing scripts. Don't do the real work. Let the scripts take care of that for you later on. Times that sometimes it's not a good idea to script.

Sometimes scripts just get way too complicated. You need to understand that there's a break point. After you've put too much effort into a script and it's still not going anywhere, or the situation is just too complicated, don't script it. Lay back, let somebody do it, maybe yourself. And definitely leave some exciting things. If you scripted everything, you're going to be bored. So a nice mix of both of those is good.

So now we get into the religious war, all right? Because I'm sure we have people that are all from AppleScript, or bash, or shell, or ZSH, or any of the other ones that we might have available to us here on OS X. So which scripting language? Which one do you want to pick? Especially if you're new to scripting, there's a lot of different options that you have out there. Which one do you want to use? Which one is going to be more effective for you? So a couple of thoughts on that. First of all, these are at least-- this is a non-exhaustive.

But what I found with a little bit of poking around, scripting languages that are included in OS X. So the three that we're going to talk about here on the top, AppleScript, Shell, and Perl-- Python, Ruby, TCL, PHP, Expect-- all of these are scripting languages that are included in here.

So definitely take the one that you like the most, the one that works best for you, and start using it. All of these can do things. Some do them better than others. But almost every script will be able to accomplish what you're looking for if you bang at it hard enough.

Some other ones that people like that aren't included in default install but are easily to install, download, package install, or whatever else. Smalltalk, Fscript, Frontier, Real Basic, and so many others. Slashdot recently had an article about comparing scripting languages back and forth. And there were some 30 or 40 different options that were on there that they had run through some code to see who was the fastest and all the rest.

Important couple of points about picking a scripting languages. Does it do what you need? It seems basic, but I know a lot of people that forget this one. They're convinced that the script that they know, the language that they understand is the one, all, end all scripting language.

And they don't even look at the other ones. So you got to understand if your scripting language that you're using doesn't do what you need, obviously you need another scripting language. Joel Rennich Do you know the language? If you don't know it, it's going to be a lot harder to script it. Not that you shouldn't learn a language, but just keep in mind that you know what you know.

Will you be able to run it where you need to? One of the reasons why we're talking about Shell, AppleScript, and Perl is their default on the install. If you go out and you create a real basic script, you create a small talk script or something else, you're going to have to put that scripting environment on the other machines. So depending what your deployment that you're looking for is, make sure that you have a scripting language that's viable for that deployment that you're looking at.

Most scripting languages will be able to do most things. Don't believe the hype, OK? Scripting languages are very powerful. And if you work at it long enough, the beauty of a script is that there's all kinds of possibilities that neither you nor the developers of that language ever really thought about to begin with. And there's usually a lot more than one way to do things. All right? So if you have a scripting language that you know that you're fairly confident with, familiar with, see if you can do it, put a little work into it.

Finally, one of the most important things about scripting. Some will do it better than others, some won't, but they'll all get it done. I tried very hard to stay away from any kind of speed comparisons or anything else in here. Because scripting isn't about speed. If we wanted to get the fastest job done as possible, we'd write an actual compiled application. We'd get out Xcode, we'd write an Objective-C, we'd compile it, and it would beat the pants off of anything that we could do with the scripting for the most part.

Joel Rennich I tried very hard to stay away from any kind of speed. If we wanted to get the fastest job done as possible, we'd write an Objective-C, we'd compile it, and it would beat the pants off of anything that we could do with the scripting for the most part.

Scripting is not a hack job. It's not a Band-Aid. Scripting is very much an integral part of your system administration. It's not just something that you worked up so that you could be lazy. Being lazy isn't a bad thing, but scripting isn't a hack because of that. So many scripts are much more than full-featured applications. I've written a couple shell scripts that were like 1,200 lines long. I go back and I try to understand what they do and I can't even remember.

All right. But they're very complete, very full functional shell scripts. And they do whatever an application would do. I couldn't find an application that would do that. Scripting was the least path of least resistance for getting that. They're not a replacement for network administrators. All right. You just need intelligence on the job. And that's a network administrator, not a script. You need the ability to make decisions like that. I shouldn't have. That goes without saying. And again, not faster than an application, but almost always faster to develop. Joel Rennich Especially, we're not programmers for the most part in here.

This is scripting for system administrators, not for Cocoa folks. So we can write these scripts, we can make them very easily readable, we can make them very easily usable for our other administrators that work in our same organization. Very easy to deploy, we don't have to get into the full blown programming language. Again, we're not going to be faster, we're not going to be maybe even more complete, but we're going to be able to get the jobs done that we need to get done.

So first off, AppleScript. One of the important underlying features of AppleScript is its interaction with the GUI. Perl and Shell both have huge amounts of features, but they're not going to be able to interact with the GUI in the way that AppleScript does. So let's take a look at some of the things here. So it started off as a language to control other apps.

However, it's completely fully functional in its own right. You're going to be able to do almost anything that you want to do with an AppleScript that you can do with the other scripts. Mostly because we can do a lot of interaction between them, And that's what we'll get into a lot of here.

Closest to spoken English, a lot of scripters use this as their gateway language. When you become a network administrator and you have fun with the GUI and it's exciting and man, those icons are lickable and they look all great and everything else. But when you move on to the next step, into writing your own things, into being able to do your own processes and control your entire environment the way you want it, AppleScript is many times the entry, the gateway drug into the scripting. So it's a great place to start. Very easy to pick up.

We'll give you some basic ideas. about how to script, what scripting will be able to do for you with a minimum of effort at the beginning. It's been in the OS and System 7, right? It's been around for a long time. It's going to be there for a long time. Again, this gets back to your deployability. If you have a script and you need to cover a vast majority of the OSs, AppleScript is the way to go.

So primarily the only GUI scripting language, a couple of features of that. One, scriptable apps. If I have an app that has an AppleScript dictionary, I can actually use it. I can tell Photoshop. Well, Photoshop's not a good example of that. Tell Quark. I can tell Quark to do something. I can tell other applications to do something through my AppleScript. I don't necessarily have to write an app or really increase the power of that script, because I can have another app that can do it for me. Plus, it's got the GUI scripting on it.

So that way, I can go in, I can create dialogues, it's got the blocks to pop up, say things. We'll show you some of that, too. It's easy to pick up. Folder action scripts are another powerful feature of AppleScript. I can attach an AppleScript to a folder. Any time a new object goes into that folder, I can do something, depending on what that is. Spoken English syntax means it's really easy to learn. I can do things like tell this application to do this. Tell the application finder to display a dialogue that says, "Scripting is cool." That's an AppleScript.

All right? It really is that easy. It's really easy for a lot of places. AppleScript Studio. Who uses AppleScript Studio? All right. I'll show you a couple examples of that. But it's an incredibly easy development environment, a rapid application environment that you can easily get your development up and running very easily. Recordable.

All right? This is maybe not as useful as it always should be. But recordable AppleScript will get you into the vein of things. I can hit a record button, I can do some actions, I can look at the AppleScript that's generated from that, and then I can refine from there. And especially for those of you who are just starting out with AppleScript, it's one of the greatest ways to get into AppleScript.

Just do a little recording and see how the syntax works. Some disadvantages to it. It's a spoken English syntax. You get used to the idea that I can tell application QuarkXPress, produce next month's catalog, put all the things I need to in it, and make it look great.

Obviously, that's not going to work. That's not in the Quark dictionary. Well, the make it look great isn't it? Yeah, the other stuff is. So you've got to be careful with it. It's definitely a double edged sword. There's a lot of times that you're thinking it sounds right, but it doesn't work. It's single threaded.

You can't do more than one thing at the same time. That's just the way AppleScript is. We'll talk about some ways to get around that. And it's only on the Mac. If you're in a mixed environment and you're looking to deploy a scripting solution that's going to work on both the PCs and the Macs, AppleScript is not your answer.

Not anymore. Starting with 10.3, you don't need to be logged on for AppleScript work. If that was the case, you'd be on here on the list. So here's a sample AppleScript. This is going to check for enough free space on your finder volume. This might be something that you use when you log in, just as kind of an idiot check to make sure that you're not overwriting your drive, right? OS X gets really, really cranky if your drive gets full. So this is tell application finder.

If the free space of the startup disk is less than some really big number, because I counted it in bits, I think, then empty the trash, beep, display a dialog box, ack, I feel full. Say that I need more room. So I have three different. I have an audible. I have a verbal. And I have just a beep that goes on when this happens. So now I have to know that something's wrong. So this is the kind of stuff that we can do with AppleScript.

Obviously, this is kind of a silly little example. But you can see kind of the level of interaction you have here. I can empty the trash. I can beep. I can say things. I can display dialogues. These are all GUI interactions that AppleScript is very, very good at.

So let me show you something. Who's running an OS X server? Hey, cool. All right, so let me go to the demo if I could. All right, so you've got an OS X server. Problem is that you need to get your users into it. The only thing that you have is you've got the accounting system, accounting department, to give you-- uh-oh, demo.

There we go. You got the accounting system to give you a list of first name, last name, and password. But man, this is going to be an awful lot of pain if you have to go in by hand into Workgroup Manager and enter all these in. So you say, well, no problem. I'll look into the server admin guide. They've got this great little utility called DS import export.

Exactly. Who's written a DS import export file? You have to get into hex. You got a lot of fields and everything else in it. It's really a pain. So why don't I write an AppleScript to take care of that? So now I have an import export AppleScript. I can double click on this. It says I'm about to run. I can pick my import file.

Here's my user import comma separated value file. Open this up. It's going to ask me a couple questions. What's the DNS name of my home? Joel Rennich Home directory server. Well, we'll just use the reverse lookup here so that works. Hit a couple things in here. Default group, default shell. Three users were imported. There's three users in this list, so that's a good thing. A little bit of error control there.

Now I've got a user import file that goes right into documents. If I look in my documents folder here, is what you would have had to have done by hand to create a working DS import/export file. All right. So this is the power of scripting. Once you do this once, you're going to sit down, you're going to read that documentation, and you go, my lord, this is not what I ever want to do again.

And so a script can really make this easy. So I can open up this AppleScript for you and show you a couple highlights in it. And again, all of these are going to be available on my site. There's a URL in the end here, so you're going to be able to see that. So here, I copied it onto the desktop. Import AppleScript, open it up in Script Editor.

tried as hard as I could to put more comments in it than code. And I think I did a pretty good job. But if I didn't, you can ask me questions about it. So it goes into here. There's a couple of things. We're using dialogue boxes, open save dialogue boxes, to interact with the user, because we've got to put some information in there.

You end up with this record. We didn't have to go down to the command line. I didn't have to tell you that you want to run this, put a bunch of flags into it, and then run it through a Perl or bash script or something else like that.

Both of those languages would have been able to do this. But now I have a much lower barrier of entry for admins to be able to use this application. So that's one example of AppleScript that can really help you out as a system administrator. If you go back to the slides, please.

An incredibly cool feature of AppleScript is its ability to call shell scripts from within AppleScript. And again, one of the things that I was talking about is hopefully I can highlight on a lot of ways that you can take maybe existing administration tools that you already have, that you've written in bash, that you've written in Perl, that you've written in another language, and use them with the other AppleScripts or use them within each other. So this example here is we've got a finder intrusion detection system. And what it's going to do is it actually runs a do shell script command. If you're familiar with the last command, the last command returns back who was the last person to log in.

All right. So by running this, we're going to run it into a loop. It's going to constantly run the last command. And if it sees that somebody new has logged in, it's going to display a dialogue for me. It's a really stupid intrusion detection system. But it gives you an idea of how we can use the do shell script command.

We're not even really calling a shell script. We're just calling a shell command. All right. Just the last command. We didn't have to write anything else for that. But now we can easily interact with it into the GUI. If I could be back on the demo again, please.

So here is my AppleScript IDS intrusion detection system. And it's going to sit up here and it's going to run in the background. And I'm going to open up a new finder window or a new shell and I'll SSH localhost and type in my password. And then if I look in here, it says, hey, the user Apple just logged in.

All right, because it's just going through and getting that last line of the last command. All right, so now we have an intrusion detection system, hopefully highlighting the interaction with the do shell script command. And stuff like that. We'll do a lot more of this in another couple of examples. All right.

Back to the slides. Great. Thanks. So that's the AppleScript IDS. So some common examples of AppleScript that you'll find on your system. Carbon Copy Cloner. Who's used Carbon Copy Cloner? All right. That's an AppleScript Studio application. It's written in AppleScript. It does some shell interaction. We'll show you some examples of that in a little bit when I actually will build an AppleScript Studio app for you. All right.

iTunes Helpers. Everybody likes iTunes, right? And there's a bazillion things that will show you your word count or your song count. We'll display the current track and your iChat status, whatever else. Almost all of those are AppleScript. Joel Rennich And then finally, Print Center Repair. Anybody using Print Center Repair? All right. It's killer for fixing printer problems. It'll go through. It'll erase your CUPS directory, whatever else, your temp files, and all that other stuff. Rebuild it. So that's another example of an AppleScript Studio application. All right.

Shell, just like the command line. Everybody loves the command line, right?

So it's the built-in scripting function of the shell. One of the oldest forms of scripting. You can really get deep into shell, and it's been out there for years and years and years. The beautiful thing about that is there's thousands, millions of example code out there. When doing shell scripting, you should have to write very little of it yourself.

After having done a lot of shell scripting for the last year or two, I've got my own library. When I go in to create a script, I don't even think about starting off with a blank page. I start cutting and pasting from the last one that I used. It's really nice.

You can do the same thing with AppleScript and stuff like that, but shell has a much larger body of work that's outside. Some advantages. Like I said, just like the command line, only automated. It's simple. If you can use the command line interface, you can use a shell script.

Just take a copy of what you're typing in. You can paste that into a text file. You can run that as a shell script. It really is that simple. Very few terms. The shell scripting language is very simple. There's not a whole lot of different things that you can do with it, but you can plug those together in very interesting ways. Relatively portable. Most Unix shell scripts will work on OS X with little or no modification.

I'm talking to somebody from developer relations that was talking about a lot of people coming from Solaris that wanted to migrate their Solaris scripts over to OS X, and they just had to swap out a few commands and that kind of stuff, and everything worked. So if you already have a body of administrative shell scripts, those will work very well on OS X.

Some disadvantages. There's no GUI. We can't display dialog boxes. We can't have it say things or stuff like that. Part of that is good. Part of that is bad. So we can use AppleScript, though, to pull those things out. I'll show you an example of that in a little bit.

Joel Rennich Hard to do some shell scripts, especially when you require interaction. You have to get into expect and some of the other shell items if you want to, for example, pass a password back to the command line interface, things like that. It's very hard to start up an SSH session that wants to use a password through a shell command. So you've got to be careful with that. Joel Rennich Check your shell.

Not all shells can do the same things. The default shell on 10.3 is bash. Bash has some slightly different functionality from some of the other shell. Joel Rennich The other shells that are out there from TCH and the other ones. So be careful when you're getting deep into it.

However, from the beginning standpoint, on the entry level, on the face of them, they're all pretty much the same for what you're going to be looking to do when you start off it. Joel Rennich And make sure you specify the one that you actually want. I'll show you what that means in just a little bit. Because if you think you're using bash and you end up using TCH and you're trying to do something, it might not work. All right. So I'll show you how that goes.

So here's a simple mail server backup. You're running an OS X three server. You love Postfix. You love Cyrus. But what happens when you try to back up the database? Well, it's live. Well, that's not such a great thing. You know the backing up databases when they're in use might lead to problems. So you want to shut down the mail server. You want to copy over the backup database. And then you want to start the mail server back up again. That's cool. But you don't want to be up at 3:00 in the morning to do it.

Another important thing to see here is the server admin command on that third line down. Server admin command is a shell command that allows you to do anything that the server admin utility can do. So instead of me having to worry about how I know how to stop post fix, how to stop Cyrus, how to stop all these other things, I can just say server admin stop mail.

And the server admin framework does all that stuff for me. So I don't need to worry about it. Thank you, Apple. All right. I don't have to do that extra work. Now I can just kind of glue together the different pieces and make something that really works out for me. So then we use R-Sync. We sync it from one, the varspool IMAP file to our X-Raid because we all have one of those. Then we actually tar it up. We tar up our Etsy post fix directory that has all our configuration files and everything else in it.

Because maybe you've looked around the web, found some articles about how to do spam and virus controls and stuff like that. And I don't know where you got those. And understand that you need to back those up in case anything happens to them. So this script will do both of those for you.

And then we do server admin start mail. We're even real nice and verbose about things. So we use the logger command to write commands, write lines to the logs for the syslog. And that way we know that we started and stopped the systems and everything else like that. One, two, three, four, five. Six, seven lines.

And you won't have to wake up at 3:00 in the morning every day. So from this base, you can take this, and we could do all kinds of crazy things. We could set it up so that every day of the week, we back up to a different folder.

All right, now we've got incremental backups or differential backups between all of this. Oh man, things are great. We can do all kinds of cool stuff with this. But this is a very easy, very simple way to get into this. And again, this isn't a hack. All right, this is doing everything the way that we needed to do backing up the mail database and going from there.

But

So I've taken that shell script that I had. So if I go to my scripts folder, there's a mail back. This one is a little more full-featured. I'll pop this up a little bit. And let's see how many lines we have here. Shell line numbers.

So we got about 170 odd lines here. I bet you over half of those are comments. All right. So this goes through, it backs up not only the postfix spool files, but the Cyrus spool files, asks you if you want to back up the postfix backup directory. Plus it has a restore functionality in here too. Because once you back it up, maybe it would be important to know how to get it back to where it should have been when you need to roll those changes back.

So there's a restore functionality in here, and now you can feed it a bunch of switches on the command line and get through some of this stuff. But again, this is exciting. But I don't want to have to go down to the command line to do this all the time.

Beauty about OS X is Macs are for grandmas, right? Even grandma system administrators. So I want to be able to let those users use this script without having to go down to the command line and mess with it. So to do that, I've got a little AppleScript Studio application here.

Get rid of some of this. Called mailback GUI. We open it up. It's got a little setup here. I can specify a backup directory. I will just do /temp in here. I put in my admin password. Important to note, one of the failures of AppleScript Studio currently-- and I haven't hit some of the other sessions if they fix this-- but is authentication. So when I pass my password here, it actually does essentially a sudo on the command.

It takes a little bit to load up because I didn't do all the stuff. But this is some of the cool things that you can do. This is the cool Mac stuff. So this is eventually what the site's going to look like, I think. We're going to do some stuff over there. But anyway, so now you have a web browser.

So while that shell script is working on your mail backup, you can check out your new web mail, whatever else that you want to go through there, surf the web a little bit, and go from there. Because as your Cyrus database gets bigger, maybe it takes a little bit longer. So real quick, you probably want to see this in Xcode. And I can show you how simple this was to set up. So here's the mailback GUI file. We'll pop this open into Xcode.

And here's the AppleScript that runs it all. And it's maybe a dozen, two dozen lines of code. Goes in there essentially just doing the shell script command and calling that shell script. I embed that shell script exactly like it came out of when I was done with it. Embed into the resources folder in here. And then you can go into Interface Builder and you can set things up with that. All right? Beautiful thing about Interface Builder, if you don't know about WebKit, let me go back here and let me show you all of the code.

for the web browser, right? But wait, there is no code. So some of the fun stuff that you can get into with Xcode and stuff like that. So really easy to wrap an Apple Script Studio wrapper, a complete standalone application. I can put this onto a disk image, I can ship it off to people. They can just double click on it, fill it out, and go from there.

Since I know it and it's my application, I can even go into and do things like already pre-set up the backup path. So I don't have to type that in all the time. Change the default URL in the web browser. Maybe you don't want that. So you can go in and you can set up a lot of things like that. So don't be afraid. This is very easy to get into. Use this example, start doing your own stuff, start taking a look at that, and very quickly you'll be turning in your shell scripts into GUIs.

So also goes, like I said before, if you're migrating over a number of shell scripts that you had set up on your Unix or your other platforms, Apple Script Studio will allow you to make an easy, nice GUI wrapper for that. Wonderful. If I could go back to the slides, please.

So you saw the backup and you saw the GUI, so we've got through there. So some interaction with AppleScript. I've got a shell script. And instead of being called by an AppleScript, I want the shell script to call an AppleScript. Specific example of this, about a year ago I was working with another gentleman to work up a FileMaker Pro startup item. If you ever used FileMaker Pro 5.5, you wanted to launch when you started up the system. They fixed that now, so don't have to worry about it, but it makes a good example.

Joel Rennich Specific example of this, about a year ago I was working with another gentleman to work up a FileMaker Pro startup item. If you ever used FileMaker Pro 5.5, you wanted to launch when you started up the system. They fixed that now, so don't have to worry about it, but it makes a good example.

Maybe you put it in your applications folder, maybe you didn't. I'm a big fan of the Mac. I want to be able to arrange my environment the way that I want it to be. So as an admin, as somebody that's producing scripts, I want you to have that same functionality. And I don't want to have to tell you you've got to go into the startup item and you've got to edit that field and figure out where your actual install is.

Joel Rennich So instead, if you went to the package installer session, you probably learned about post-install scripts. These allow you to have a package that installs and then kicks off a shell script. That's cool, but my shell script can't display a dialogue that actually lets me know what I need to do. So to get around that, my shell script can call OSAScript. OSAScript is a command line way of actually calling an AppleScript. So my package installer actually installs an AppleScript, then runs the post install script, which runs that.

A little, eh? Fair enough. All right, you with me? All right. So that AppleScript then displays a dialog box. It says, hey, why don't you pick where your server application is for FileMaker Pro Server? Once we're done with that, then it passes it back to that post-install script. The post-install script goes through and edits the startup item and makes sure that it knows where it is. And so you can see a quick example of this. Up at the top is the shell script.

It says "mypath=osascript," and then we're calling that AppleScript that we installed somewhere. That AppleScript, which is the second half, says "application finder activate, open up a dialog box to choose a file, please select your application, set the path to the POSIX path." That just makes sure that we convert it from the AppleScript way of file locations to the shell way. Return that, which goes right back to the OSA script, and then we're done.

So there's the OSA script command. It was a scripting session. We had a hard time trying to find out ways of making the graphics more exciting. So you see how that turned to orange? All right. So that's about as much excitement as you're going to find in here.

All right, so let me show you that. If I could go back to the demo machine, please. I tested it on here, so I need to remove the, this is our startup disk. I need to remove the receipt from it real quick. FileMaker Pro Server, there you go. Gone. All right, so I go into my scripts folder with all my stuff in it.

I've got a nice FileMaker Server startup item. We mount it. Nice package installer that comes up. Beautiful little graphics and stuff that we have in here. Little RTF with the motion. Look at that. All right. I'm not a graphics guy, but this was easy. Select the volume. I'm going to install. Ask me for my password.

So now it's actually installing the payload of the application. This is the startup item. This is a couple of other things. The startup item, however, doesn't know the location of the application. So now I've got a dialog box that pops up. Where's FileMaker Pro Server? I can go to my Applications folder. I can pick that out.

FileMaker Pro Server isn't on here. Then it passes it back and it does that. software was successfully installed. So now, if I go back to my startup items, library startup items, You can see there's an FMP server startup item in here. If I look inside here, here's the actual startup item show item.

: There we go. That's easy enough. And it went through and look at here. Here's a line.

So if we go into the startup, the package, show package contents. Inside contents, we've got resources. Inside resources, we have the post flight script, which we can open up here.

And sed gets a little ugly the first time you see it. But there's a tiny little sed command. Sed doesn't get any better. Tiny little sed command in there that in my default item that I installed, I just had a little comment that said, going to be replaced by script, which made it nice and easy to find on the way back. So I took the output of that AppleScript, that dialog box that came up, fed it back to the shell script.

Shell script then goes back in and changes what I installed. Beautiful, right? And I can even go in. And if I go into my hard drive again-- and I did a bad thing, because I kind of left that AppleScript around-- Startup Items, FileMaker Pro Server, and in Resources, Here's an AppleScript, which we actually feed to OSA script.

So this is the contents of the AppleScript. So again, I installed the AppleScript on the hard drive and the package installer as part of the payload. The post-flight ran the post-flight shell script, which called OSA script, to call the AppleScript that I knew where it was because I installed it there. AppleScript found out where the FileMaker Pro server application was going to live, passed that back to the post-flight install script, which then edited the startup item, and then we're done.

All right? That was the most complicated way I could find of having one call the other and back. So some really fun stuff that you can do with that. And now again, hopefully you can see that you can easily, easily, easily put this kind of functionality into your own scripts, migrate over your actual shell scripts that you had before, put that into here, and do a lot of work with it. If I could go back to the slides, please.

Some common examples are shell. I was looking for ones that were in the default install here, so some of these might be reaching a little bit, depending on what you call common examples. But the Etsy daily, weekly, monthly scripts, those are all shell scripts. Those are the ones that go through, back up your NetInfo database, rotate your log files and stuff like that. So those are in there. Startup items are commonly shell scripts. If you look in system library startup items, you're going to find that the actual executable of a startup item is almost always a shell script, because it's nice and simple.

If you've ever used the disk space monitor, I did a grep on the system looking for anything that had been bash in it or something else like that. Disk space monitor alerts are there. And pre-flight and post-flight package scripts are most always shell scripts, although you'd see a lot of Perl lately too.

never use another scripting language again, right? Once you lose, right? Once you use Perl, you never go back. Having said that, I stick with shell, but I understand where people come from with this. I started off mostly doing AppleScript because it was easy-- it was very easy to get into.

Once we started getting into OS X Server, especially in X1 and X2 when AppleScript wasn't as robust as it is now in X3, shell scripting took care of some of those deficiencies, stuff like having to be logged in and things like that. So shell script I started doing a lot of work with and having a lot of fun with the interaction between it. Some would say the next logical progression would be to Perl. Takes a different person to understand Perl, so we'll go over that.

Perl is present on pretty much any Unix system. So again, you have a wide range of deployable systems that you can write a Perl script for and use. There's many, many, many, many Perl resources available. There's a lot out there, just like shell script. There's thousands of sites devoted to this, thousands of sample scripts that you'll be able to get to. And an incredibly active, and for the most part, very nice developer community. Happy to answer questions. Just don't get them into wars, and you should be good.

So some advantages of Perl. It's very much multi-threaded. You can do a lot of things at the same time. Perl's got a lot of resources available for that. This is verging on a religious statement, but I think it's the most extensible of the three languages, mostly because there's thousands and thousands and thousands of modules that have been written for Perl. Again, I hate to pick on Carbon Copy Cloner, but since Mike's doing the ARD session, I will. If you've used ARD, you've used PSYNC.

PSYNC is a Perl app that uses a bunch of modules that use it in there. Again, you could use those same modules to increase your own Perl application. So that's one of the examples that uses that. CPAN is a Perl repository. I'll give you a URL for that in a little bit. That's got a listing of all these modules that you can easily get to. Runs on most systems. Although it's not in there by default, you can get Perl environments for BAC as OS 8 and for Windows.

So even though it's primarily installed on most Unix systems, if you want to, if you have a Perl script that you want to use with a little bit of tweaking and some installation on the client side, you can get this to run on your clients. Incredibly good for text processing. I've lately started getting into helping out a design firm that I was working with that needs to get rid of a bunch of files generated by their rips and stuff like that.

And the file path got so weird and so complicated that Perl was the best solution for that. Because it can easily get in there, parse out that text, do a lot of text manipulation without having to go through and do it by hand like you might have to code in a shell script.

And if you've ever done anything with Perl, one of the slogans of Perl is there's always more than one way to do it. And as you'll find out when you go looking for Perl modules to do your one item that you need to do, you might find 3,000.

So you got to wade through that a little bit to decide, hey, which one's better, whatever else. So there's a little bit of a learning curve there and maybe a little bit of a sense of overwhelming how those all are out there. Perl disadvantages. It is probably, I don't think anyone would argue with me that it's the most complex of the languages that we're talking about here. Not that that means it's hard to learn. It's just that there's a lot more syntax that you need to get used to.

There's a lot more commands. There's a lot more of statements that you can get with. So you need to understand that before getting into it. It's not something that you can just pick up a visual quick start guide to and be writing a lot of Perl within a day or two. It might take you three or four days. And to get the really good stuff, take you a little bit longer than that.

But there is going to be a bit of a learning curve. You'll actually have to think. With AppleScript, we can do some recording and stuff like that. We don't have that functionality with Perl. So again, there's a little more into it. And there's more than one. There's only one way to do it.

So when you approach a problem with Perl, if you go looking on some of the lists and stuff like that, you're going to find 18,000 different ways. And you have to kind of filter through that a little bit and say, really, which one is the best way? All right, here's a simple Perl script.

I wrote an application that generated SSH tunnels. It was an AppleScript Studio application. Problem with it was, is once it calls the do shell script command, it would have to wait for that do shell script command to return before the AppleScript Studio application actually went back to being operational.

So one of the ways around this was to actually wrap my shell command into a Perl script that would actually demonize itself. So this is one of the examples I could find of Perl that I would have written that did something kind of sexy. So it demonizes itself.

Joel Rennich All right, here's a simple Perl script. I wrote an application that generated SSH tunnels. It keeps that SSH tunnel open as long as it needs to. And the AppleScript Studio application had a return because this application, this Perl script had spun off and had kind of gone on its own.

So the AppleScript Studio part was happy to go back to it. There we go. See that action? Difference between this and a shell script, it's just text. It's different text, but it's just text, is the fact that we're using user bin Perl here instead of bin bash or one of the other shells we might have had.

Here we have a Perl script demo. Auto printer setup. Is Mike here from Purdue? Maybe not. This is a Perl script that an admin from Purdue set up. And let me show you a problem. I'm a user. I sit down at the lab machine. I say, oh, no printers.

Let me add a few. I want to add an LPR printer. It's at my house. This isn't my home IP, but we'll just type in something here. It's going to be a generic PostScript. I don't want to get anything fancy there. All right, generic postscript, and I add it.

Okay, cancel. Do I have a printer in here now? There you go, generic PostScript printer. All right. Problem is, the next user behind me isn't going to want this printer. I'm in a lab situation at a university. I don't have the luxury of having an OS X server and work group manager that I can push down and force users into different printers. So instead, I kind of got to do this myself. Perl to the rescue. We've got an application called Printer Setup. I'll pop all these open so you can see these.

going and it is a Perl script that looks inside two different files. So here's the Perl script and again you can take a look at this and go through it and see some of the stuff and it reads in from two different files. One is a printer definition file which understands what printers are available to my client machine and the other file is a printer mappings file. This says hey if this machine's IP address is in this range we're gonna install these printers on IT.

So two different data files, both in plain text. And we're just going to use the LPR commands, the LP commands, to set up print queues and stuff like that. So let me show you a quick example of that. So I'm the lab admin. I come to this machine. I say, why do they keep adding printers? Go down to the command line. I've got to run this as root and volumes. There you go. Let me just drag that in, right? This is too much work.

Beautiful. Now I go back to the printer setup. Hey, it's not that 17 IP address LPR machine anymore. Now we've got the WWDC demo machine. Come on. There's something for that, right? It went in. The Perl script goes in, it deletes your current folders that you have, it looks in the data files, finds out what printers you're supposed to have, and adds those printers in with the LP commands. Nice example of what you can do with Perl and some of the stuff that you can get done with it. If I could go back to the slides, please.

Common examples of Perl, part of the server setup process runs a Perl script that goes through and does that. If you have a website with an SSL certificate that's actually got a passphrase associated with it, when you launch Apache, it actually calls a Perl script that pulls that out of it. Disk Space Monitor does this. CGI scripts on web pages, right, the vast majority of those are probably Perl. I'll go on a little bit of limb and say that. So examples of Perl that you'll find around.

All right, some links that you can go to for more information. Here's the URL for the sample scripts. So [email protected]. Those are out there now. So you'll be able to grab those. Internet and web documentation, you can go to the ADC home, some of the other stuff there. Here's some man pages for bash, Perl, and others. Then we've got some example sample script sites that you can go to and download some stuff from. Notice for shell, we go to Google.

I couldn't find one that was as inclusive as I wanted it, and I didn't want to put 30 up there. So literally, when I go looking for shell script examples, I Google bash, printer setup, whatever else, and go through there. And I'll be able to find that. So thanks. That's my site. My email is supposed to be up there, but it's [email protected]. If you go to the site, you'll find it.