Good afternoon, and welcome to session 613, Migrating UNIX SysAdmin Tools to Mac OS X. I think we have a really nice panel of experts who are going to tell you about various experiences, moving their tools over to Mac OS X that will be very helpful. We already know that Mac OS X is the best development environment. It's also a fantastic SysAdmin environment. And using all these Apple technologies, wirelessly connected, being able to manage giant racks of servers in your data center is a blast. It's a lot of fun.

Today we have Kevin Boyd, who is going to, from the University of Michigan, who will explain what the environment is like for the University of Michigan, and their experience in bringing over their tools for a very diverse group of SysAdmins and managers. Next up, Waqar Malik, of our developer technical support, is going to explain some of the gotchas, importing over some of your scripts and tools and applications you've written.

And finally, Mike Bombich, of our field. He's one of the world's leading field consulting engineers, well known for his work on the side and his fantastic tools that we all use. He's going to describe how to build a great GUI interface on top of those command line tools.

So first up, I'd like to introduce Kevin Boyd, University of Michigan, and on the steering committee of MacOSXlabs.org. Kevin? Thanks a lot, Skip. Hi. Today, I'm going to talk to you guys about how we as developers can work with administrators from all different types of computing platforms to create applications that administrators will want to use in Mac OS X.

Who am I? That's a good question. I'm an administrator at the University of Michigan, and also I am one of the steering committee members for the UEF lab group that also runs the site that's known as macostenlabs.org. And my responsibilities primarily have been, in relationship to this project, the development of lab management tools that ease the transition from some other computing platform to Mac OS X.

At the University of Michigan, this is a very complex environment known as a distributed computing environment, which has a lot of potential challenges for administrators and developers. Because of the distributed computing environment, there's the ability given to our administrators to pick any type of computing platforms and any type of operating systems that they may want to run inside of their own environments.

And we'll get into more detail--

If we go back in time, we can look at how Mac OS 9 was managed at the University of Michigan, and we can start to see why administrators liked the Macintosh experience when it came to managing machines in their environment. It was easy to manage because of the operating system.

It had an easy-to-use interface, it was intuitive, and it didn't take a lot of learning for you to understand how to use a Macintosh computer. It was accepted for users to go out, administrators to go out onto the net, contact third parties, do whatever it takes to make the machine a secure and consistent computing platform for you inside of a lab management environment.

At the same time, on our campus, we had many other platforms that were UNIX-based. And these people had skills that allowed them to manage their machines, but the learning curve was incredibly steep. And the ability to manage the machines was incredibly difficult. And these two groups really could not have skills that transferred from one group to the other.

We at Michigan saw Mac OS X as an opportunity to take all of our experiences creating utilities and tools for managing machines in OS 9 and in UNIX and combining them in such a way that we could have truly the holy grail of computing and lab administration, which would be ease of use, ease of migration, ease of integration, and also to be able to say, I have skills that I've gained from learning how to use this machine that can be transferred from other computing platforms. I have a skill set that applies not only to these Macintosh computers, but can also be used in other environments as well.

So we've leveraged our experiences in these environments, and we've developed applications that you've heard about throughout the week or at our site, or we can talk about them here too, that have really taken advantage of all this experience. The challenge has been, how are we going to continue to make tools that administrators want to use? So let's take a look at one of the places where I had a chance to spend some time at the University of Michigan developing tools for Mac OS 9 users.

And from there, we can decide whether or not these are-- why was this so successful? What did we do that was so successful? What happened here that we can tell developers, go out and do this, and it will make Mac OS 9 users want to use Mac OS X? As we've already stated, the University of Michigan is a distributed computing environment, and with the freedoms that we allow administrators to have, it presents enterprise computing at its most complex level, because there's freedoms in terms of hardware, software, data, people, and procedures that we let the administrators have in order to create their computing environment.

At the same time, we want to have the users that use these computers' computing environments to have a consistent computing experience from one lab to another. So let's focus, narrow our discussion a little bit, and talk about the School of Art and Design at the University of Michigan. I spent a lot of time with the OS 9 administrators there, and that's really where I became involved in OS X.

So here we have the traditional view of Mac OS 9 and why people like using Mac OS 9, and we have the traditional view of UNIX and how people use UNIX and what was good about each platform. Utilities like Assimilator were nice because, well, to put it simply, it was easy to use.

It didn't require you to know a lot about the underpinnings of the machine in order to manage a large set of computers in your computing environment. However, tools like this and almost all the tools that were available for Mac OS X didn't scale. They weren't readily usable in a wide range of machines across an entire computing enterprise.

While, on the other hand, the UNIX operating systems gave you all of the network integration technologies that you needed for enterprise computing, but learning how to implement them, learning how to use them correctly, and learning how to make them fit into your environment required an incredibly steep learning curve.

So we have the problem laid out. How do we create tools that administrators will use? Well, I think the first thing we need to do is identify the expectations and the benefits that can be gained from looking at our core audience. Who are we trying to help? Who are we trying to create these applications for? I think they can be divided into three groups. You have your diehard Mac OS 9 administrators.

These are people who even today are still not migrated, still have not decided to take a look at Mac OS X. You have your hardcore UNIX administrators. These are people who, they may say things like, Mac OS X isn't a real OS. It's not a real UNIX. Well, we all know it is, and it's up to us as developers to prove to them that it is. And you have your Mac OS X administrators.

These are people who realize the power of UNIX because of the ease of Aqua and the underpinnings of the UNIX subsystem. So they have expectations as well. Meeting all three of their needs, I think, is just the first step into creating an application that not only will these people use, but it will find uses that you may never have thought of.

What do Mac OS 9 administrators want? Mac OS 9 administrators, they want to know what your application does before you even tell them what it does. They want to be able to look on the screen and know intuitively what to do. They want help in the form of tool tips or any other type of documentation on screen if it's not readily apparent to you or to them what their application does.

For OS X, they want it to look like it belongs in OS X if it came from some other operating system, even if that other operating system was a previous Macintosh operating system. And obviously, if they're running it in Mac OS X and you've brought it from some other platform they may be familiar with, it should not require any learning curve.

Hardcore UNIX administrators, of course, want things like command lines and terminal windows and man pages. I'm sure all of you heard this a million times over, and they're all there in Mac OS X. And as developers, it's up to us to give them what they want because, obviously, that'll make them accept this as a viable platform.

The question of source code comes up whenever applications are developed for any platform. And I think the openness that Apple's given us, the chance for us to give open source code out, is another learning opportunity that can show more people how to write applications that'll solve problems for their particular environments.

and there's Mac OS X administrators. They realize all of this. They've seen the light. They understand what we're talking about. They know the power that they have in front of them, and they expect all these things out of a well-written application. If your application is not well-written, no matter how good it does what it's supposed to do, they're probably not going to use it. They want everything OS 9 administrators, UNIX administrators, and other Mac OS X administrators want from this application that you've created.

The portability of your application pretty much requires that you've had experience writing this application on other platforms, but if you have, they expect to be able to use their skills and their scripts and their command line utilities that they've developed on other platforms with your application as well.

So the standards are very high for Mac OS X applications. My own experience was with RSyncX, and primarily the desire was to have an application that hit all of these goals and in the end gave us something that at the time did not exist for Mac OS X, which was a way for us to easily move files across a network.

That was essentially our mission statement for rsyncx. We wanted to be able to satisfy these audiences, solve this problem, and then provide documentation in such a way that other people could look at what we've done and say for themselves, is this something I want to use? Is this relevant? Does this matter to me? And even if it didn't matter to them, it could be a source for them to look at in order to learn for themselves what it takes to develop software for the platform.

So when we take all the pieces that rsyncx has become, the main application, the rsyncx CD, and the package tools, we see that we have all the pieces of a puzzle that actually was laid out before us long before we even knew that this was going to be the problem we were going to be solving.

And the problem was for us, how are we going to get load sets out to these machines and have OS X on all of them and do it in such a way that our Mac OS 9 administrators didn't feel afraid of making the switch? So now we've identified these audiences, and we've tried to say we're going to hit them.

We've worked-- and I are going to talk about the development cycle of the development cycle. We started out on gathering input based on these audiences, and that came from the web, it came from hands-on experiences and face-to-face meetings. And we decided that the best way to make as many people happy as possible is to create this development cycle. And this development cycle would hit the three components of a typical Mac OS X application. And those were the UNIX underpinnings, the user interface, and documentation.

Shortchanging any of these three key pieces of the development cycle would lead to having unhappy users of your application and potentially people who don't want to use your application. So we can take a look at how each of these affects the final product that you're trying to promote.

There are three pieces to the rsyncx application and the rsyncx project, and primarily what we're looking at is a command line utility, which is the rsync terminal window application. You can open up a terminal window, and you'll see, using rsync dash dash version, which version of rsync you're running. If it's the right one, it'll say it has HFS plus support.

There's a GUI, and the GUI is constantly under revision, and as of 1.7, it's still not much to look at, but it does what it's supposed to do, which is allow a user to understand how this application works, provides tool tips, and generates scripts that are highly portable so that other UNIX admins can see what you've done in this Mac OS X environment, and they can instantly recognize what you're trying to do. And not only that, they can use these scripts in their platforms as well.

Doing all these things as developers, I think, is crucial. I just don't think there's any way around it. I don't think there's any way you can take shortcuts to get to having an application that people want to use in Mac OS X, because all of this power is there, and if you don't use it, if you don't explain how to use it, your application won't be considered as viable.

But of course, rsyncx is just a work in progress, and it's just a piece in the puzzle, and it doesn't do everything. If you needed to backup machines to local hard drives, you can use rsyncx. If you needed to distribute load sets across wide numbers, large numbers of machines across a network, you can use rsyncx. Are there other tools that do the exact same thing? Yes. So there are alternatives out there. If you find them and they're more useful, there's nothing wrong with using them either.

The idea here is just that this solves a problem for a potential audience, and it's up to you to decide, how do I make my application do the same thing? There's a lot of other discussions out there about things like comments, like version tracker, for example. If you have good or bad press regarding your software, do you like it, do you not like it? I say there's nothing wrong with bad press.

There's nothing wrong with having an application that people are making comments about, good or bad. Because guess what? That means they've tried your application, they know whether or not they like it, and they're letting you know what you need to change in order for them to use it. So there's really no such thing as bad press.

And of course, when you're developing your software, I encourage you to use the developer's tool CD. Because the people at Apple have gone out of their way to create this machine that is viewed as a good cooperative network citizen. And it's up to us to make sure it stays that way. Thank you. So now I think I'm going to let Waqar talk. I believe I'm done about migrating UNIX SysAdmin Tools and porting command line tools. Thanks.

So if you went to the Apple Developers Tools for UNIX, this talk will look familiar to you because a lot of the same stuff is told in here. So you're a SysAdmin, and you have some application that you have developed. They're not shell script, but they're actually an application that you run.

So this talk, what we're going to do... show you how you can bring your applications to Mac OS X easily and quite confidently that it will work on Mac OS X. And it will tell you areas to investigate what to do and where to look for information and what you need to do.

What you will learn from this talk is supported APIs, compatibility APIs, and some different APIs that may not be equivalent in other UNIX platforms, or you have equivalent of those. And it's very easy to port applications to Mac OS X because it is UNIX. So if your UNIX application runs on another platform, it will be very easy.

So this is what your application will look like. So you have the top layer, which is your application. You have libraries that you link in, frameworks, which we'll explain later, LibSystem, which is equivalent to LibC on other platforms, but much more. And then you have the kernel and the BSD, the Mach, and the IOCit available for you. What you will need. Make sure that you do not uncheck the BSD subsystem when you're installing the OS. And when you're installing the developer tools, make sure you select BSD SDK and the X11 SDK so you can develop X11 applications as well.

So the tool chain is mostly GNU-based. So you have GCC, GDB, GMake. We also have BSDMake for transitional purposes only, but GMake is the default, and you should be using that. We have other tools like Xcode, environment that you saw in the keynote, Interface Builder, and malloc-debug for debugging, and some other performance tools that you can use to tune your application.

There are three different compilers installed on Mac OS X. Three different versions of the C compiler. So you have 3.3, 3.1, and 2.95. The reason is we want to be able to target kernel extensions back to 10.1, so you need to use 2.95, and then for 10.2, we have 3.1, and for 10.3, we have 3.1.

There are three ways you can select a compiler. The best thing to do is just use GCC Select that will set your compiler that you want, and then everything else uses that. Or you can set the option in Xcode, or you can just call directly from the command line to whatever compiler you want.

Before you're doing it yourself, if you're porting an open source application, check porting environments, porting systems that are available that if somebody has ported it already. So there's Darwin Ports, Fink, and Mac OS X Downloads on Apple's site. And if you do port it, please submit a port to these systems so that you have a large collection so the next person comes along has the application already ready to run.

Porting script is very easy. It's just the same tools that you have. So you'll see Shell, Perl, Tickle. These are all installed by default. Our Shell is Bash, so it shouldn't be a problem there. If you want to script GUI applications, Apple Script to your friend. Mike Bombich will explain how he uses that quite easily. So the end result is very easy to bring your scripts to Mac OS X.

Primary file system, we use HFS+. We have many, many file systems on Mac OS X. The main one, HFS+, has differences from the UFS, which is the standard UNIX file system people use. Case-sensitive is not there. Case-preserving, yes. So when you type a file name with a certain case, it will preserve that, but if you type the same file name with a different arrangement of cases, then it will be the same. Resource forks, so Mac OS 9 people know what resource forks are. And journaling, we have added journaling to HFS+, so it's faster and easier to recover.

RSyncX also supports HFS+, so when you're syncing files, you can take resource forks along with you. The issues come when traditional Mac users start using Mac OS X. They tend to put spaces in file names. Unix user node, never to put spaces in file names. Always use extensions, so Mac OS X users have type and creator code, so they stick with that. and then also some of the application use resource forks, so you'll have to worry about that. And Mac OS users are used to using aliases as opposed to links. And for UNIX, it doesn't quite know what to do with aliases, so you have to be careful on that.

Libraries. On Mac OS X, we have our own linker, and the way we do our libraries, it supports versioning, plugins, and we differentiate between bundles and libraries. The extension for the libraries is Dylib. So if you're used to .sos, you have to be careful. Static linking is very rarely used, so everything is pretty much shared. Frameworks. I'll explain what frameworks are, which is also available. And lib system, which is, encompasses a lot of Mathlib, Lib C, and other libraries that just sits at the bottom so that everybody can access that. Bundles.

What are bundles? Bundles are... Things that you put together and make an object. So you can put executable code, Other resources such as language translations and things like that, or you can have multiple architectures in the bundles. And it's very easy. You just drag one item in the finder to install and to uninstall. And examples are you have frameworks, which are bundles, and compound documents such as RTFD, which has text and images.

and frameworks. Framework is a bundle where you have the actual library, the headers, the documentation, other resources that go along with it so that you don't have to put your headers somewhere else and the libraries somewhere else. They're all in one nice, neat package, and they can be moved around easily and they can be used.

System libraries are installed in system library frameworks where you should not install those because Apple reserves that place to install their own. But you should install them in either slash library frameworks, network library frameworks, in your user's home directory library frameworks, or in the application's contents frameworks, depending on how you want to expose the framework. So, depending on how it's done. Two-level namespace.

It's a very large issue or topic that can't be covered in this talk, but it's basically how you access variables with the same name in global space because we can have the same name in different bundles and frameworks, so there's no collisions and things like that. And it was default starting in 10.1, but you can go back to flat file namespace if you want to, but it's not recommended. So, that's the first thing.

and David Koeppel, and I'm going to give you a little bit of a brief overview of what we're doing. Runtime issues, if you want to save preferences, system preferences, you should be using Open Directory. And if you want to save user preferences, then NS preferences and CFPreferences, they're equivalent. You should be using that. And startup scripts.

BSD never really had a good system to manage startup scripts, so we developed our own, similar to System 5. But ours is a bundle, so it has the script, it has the localization, and other documentation that you want to put in there. And they're located in system library startups for the Apple-supplied ones, and then for you, it's library startup items.

Pre-binding. Because of the speed that we want to gain from our linker, we pre-bind the symbols at runtime. So that could cause a problem for applications like backup and security because they think the file has changed. Either you can't get access or you can't back them up. So you have to be careful about that.

authentication and authorization are and David We're going to talk about the security framework. The security framework is a good place to start. The system is rights-based system, so you give a right to a user to perform certain actions and we have great APIs to go with that. The Apple security framework is a good place to start. PAM is available for compatibility reasons only.

So if you're bringing -- you don't want to change your code, but our security framework based on CDSA is a better way to go. GUI options. We have lots of GUI options. Cocoa, Carbon, X11, and now Qt. Troll Tech has made it dual license and open source and a commercial version, so you can get a native Mac OS X version of Qt and use that as well.

For multimedia, if you want higher-level mixed media, QuickTime is the way to go. Low-level, CoreRadio, CoreMidi. Benefits is it's very fast, it's very easy...

Internationalization. We have CFString and CFLocale, which is recommended API, and now Panther has WCartT supported, and you can use that, but we would recommend that you use CFString and CFLocale because we will bring forward new... Precompiled headers.

Jaguar had a problem with this, but Panther has a new way of doing precompiled headers, and it's much less of an issue than it was on Jaguar. If you have a problem, that's the first place to start. Turn off precompiled headers, and usually stuff works. So to turn them off, dash no CPP precomp, and don't use traditional because that's not recommended. It's deprecated. Even though it turns off, no precomp, but you get a lesser level of GCC or C standard.

Linker, Apple's own Linker. It's a single pass, so you have to put your libraries and frameworks at the end of your object file so you can get symbols. Lazy initialization of variables, so it's really a problem for C++ so that your static initializers don't get called. So you have to be careful there. And it does pre-binding.

Flag is not supported, so you should be using dynamic to make dynamic libraries. So what's new in Panther? We have WCAR. They buy ConvertICU, so all the... It's new, but it's not recommended for you to use at this point because of the binary compatibility. But if you really have to use it, then you can use it. Asynchronous I.O. Everybody was asking for that.

Poll. It didn't make it to this seed, but it is scheduled to go in, so in the final release, you will have poll. DL open and DL close. Same. It's scheduled to go in, but didn't make it. The DL close and DL open library is the libcompact, which is available in Dalton ports. So in the meantime, you can use that.

and Ports Manager GUI. So this is a large collection of ports that are available. So this is a nice GUI in application utilities. You just double click and see the list of applications that are available and then just say install and then you have that application available for GUI and command line tools.

So that's it for me. And we'll have Mike Bombich come in and explain how he uses his Apple script to -- Thank you, Waqar. So Waqar spent some time basically giving you some of the logistics of moving your SysAdmin Tools up to Mac OS X. What I would like to spend some time on is telling you about how you're going to get Mac users to actually use them.

So let's face it, Mac users need a GUI. In the UNIX world, GUI is a four-letter word. In the Mac world, GUI is essential. Apple has introduced several developer tools that make this a lot easier. Package Maker can help you with any command line tools that you use to distribute software.

They've got Property List Editor in there for configuring, for editing any configuration files. And then there's some other tools like Apple Script Studio, Project Builder, Interface Builder, for actually putting a GUI onto some of your command line-based scripts. And that's what I'd like to focus my time on, is Apple Script Studio. Apple Script Studio, and I won't get into all the various acronyms that people have assigned to it.

It's based on three technologies: Apple Script, Project Builder, and Interface Builder. It was introduced in Mac OS 10.1.2, so it's only supported on that OS and higher. And it's implemented in the form of three project templates in Project Builder. And there's over 30 sample projects to help you get started coding in Apple Script Studio.

So some of this stuff is going to be fairly basic, and bear with me, but as much as this may go without saying, it's sometimes important to actually say it. Developing a GUI, step one is making sure that it works at the command line. You want to make sure that all the functionality of your script, everything that you want to get done, is going to work in a shell script in a command line environment. Once you've got everything working for one particular scenario, go ahead and generalize that shell script and make sure it functions in every possible scenario in your environment.

Another very important thing to keep in mind is these are Mac people out here. While Mac people are very, very, very intelligent, very intelligent, they are not Unix savvy in general. So you have to anticipate non-Unix user input, like maybe spaces and path names and special characters, things like that. So anticipate non-Unix user input when you're preparing your shell script.

So once you have a shell script built and it's doing all of your SysAdmin stuff or whatever, now it's time to go ahead and create a project in Project Builder. There's three options. You can make just a regular Apple script application, and this is the most common thing.

You can make a document-based application if you wanted to make something like a text editor, or you can make a droplet application if you wanted to have the functionality of being able to drop files and folders onto the application and then have it do something to those files and folders.

After you've created your project, actually the first step after you've created your project is to mock up your interface in Interface Builder. Now this is a very non-trivial step. In the Unix world, you write a shell script, it does something, it maybe asks the user to type in some text at the command line, and as it's working, maybe it dumps some text out. A GUI is very different than this. You have many different ways that you can have the user give input. You've got buttons and menu items and checkboxes.

All sorts of things like that. And then you have different ways of providing output and giving people feedback as to how things are going. So you need to think about how you're going to give feedback to the user. You've got progress bars and dialog windows and all sorts of things. So it's very important to give the end user a really good experience and not just dump out text or pop up a window and ask for text.

So once you've mocked up your interface, you'll go back to Project Builder, and then you'll attach parts of your script's functionality to specific interface objects. So in Apple Script Studio, you'll use that do shell script function to just take a particular shell script or just a particular command and attach it to an action like the click of a button. One very important thing to remember here is GUI applications are not linear like shell scripts.

You're not just going to write up your shell script and plug it into Apple Script Studio and away you go. You're probably going to have to break that script up and attach specific actions or specific commands to various things that happen within that user interface. You'll probably use global variables a lot more often because of that non-linearity.

So some of the other things that you're going to want to keep in mind are security issues. Does your script require admin privileges? If so, how are we going to get that password from the user? Is the admin user even the logged-in user? You're going to have to think about things like this.

If you just have one command that requires admin privileges, then you can just use Apple Script Studio's built-in functionality to retrieve the password. Otherwise, you'll want to consider prompting the user for the password and storing it in a variable. You also want to think about whether or not preferences would suit this utility well. Apple Script Studio provides an object called the user defaults object that you can use and access to -- you can manipulate that object to access a preference file in the user's preferences folder.

Finally, you really need to keep in mind, you need to learn about your environmental variables and your working directory. Don't just walk into this thinking that you've got the same working environment that you would at the terminal. You don't even have the same shell. There's actually a really nice tech info article, I think it's called. It's number 2065 if anyone's interested in learning about how to work with DShell script and how it compares to the terminal environment. Okay, so logistics aside, let's go ahead and move over to the demo machine.

All right. So what we have here is-- let's say that you're an IT administrator, and your supervisor has just tasked you with creating a software library. You've got several hundred CDs, and in the past, they've just been thrown on a shelf or something, and they get damaged. Actually, could you take me back to the slides? There was one slide that had all this up there.

Sorry about that. So you've got a couple hundred CDs. Usually they get chucked on a shelf and scratched or lost. And a CD is checked out, so only one person can access it at a time. You actually have to have one person that's assigned the task of managing that library. And you'd rather not do that. I don't know, maybe you'd rather be surfing the internet.

So in the end, it's just not a very good system. So what you've decided to do-- Instead of sharing the actual physical disks, you notice that in Mac OS X, there's an extensive disk images framework. And you notice that there's a really cool thing that you can do. You can make disk images of the CDs and then stick them up on your X server running the Apache web server. And then you can host these images remotely.

And with just this little command right at the bottom, you can mount that disk image remotely. So you can host hundreds of images on your server somewhere, and then people can remotely use this command and mount that disk image right there on their desktop and have access to it. So now to the demo.

All right, so the first thing you want to do is you want to kind of start out basic, just create a shell script that implements that functionality. So this is probably a bit hard to see, so we'll just blow that up a little bit. So you create a basic shell script that includes the path to that disk image, or just one of the disk images. You didn't create all 100 disk images, you just started with one. And you included that in the script, and then the first thing it does is just mounts that disk image. So we'll go ahead and run this script in the terminal.

You'll see what happens. It just mounts that disk image right there on the desktop, and you have access to all the software there. So it's a pretty basic concept. Obviously, this is not going to be very scalable. Are you going to include the URL to all 100 or 200 or 300 CD images? Probably not. So the next incarnation, you decide, hey, I've got a great idea. I'll just have the user enter the URL. This is great. I'll never have to touch the script again.

They just type in the URL. So why don't we go ahead and do that? We'll run this script. and enter the path to the remote-- path? Is it on a local volume or was it? So we'll just go ahead and type-- we'll pretend that I actually know what I'm doing.

So you get the point. Obviously, this isn't going to be a very useful solution for your end users. So ideally, you would want to keep... All of those, the path to all of those images right there in your script. So that's what we have here. So in this script, you decide, I'll just keep the addresses to all those images right here in the script, and I'll present that list to the user, ask them to choose one, and then I'll mount the one that they choose. Skip Levens, Kevin Boyd, Waqar Malik, Mike Bombich So this is pretty cool. We'll go ahead and run this script.

So it presents a list, 0, 1, 2, 3. Why don't we go ahead and pick number one and mount that disk image on the desktop. So that's another thing you can try. You realize, though, that's... That's crazy. I mean, if I want to add another disk image to my CD library, what am I going to do? Am I going to edit that script and redeploy it to the 500 people that I had already deployed it to? Probably not.

That's going to be a maintenance nightmare. And didn't we start this project to decrease maintenance in the first place? Yeah, we did. So being the clever IT guy that you are, you notice when you--

and then go out to a web page and select just the image or the directory that the images are hosted in, you get this nice little list of all the images dynamically generated by Apache. If you take a look at the source, You can see... I could parse the heck out of that.

It's got nice little tags right here. I could use that as a delimiter, and maybe I could use something like that as a delimiter. But hey, this is cool because this dynamically generated a list of all the images in this directory. Why don't I just grab that list, parse that list for the images, present that list of images to the user, the user picks an image, I mount the image. So why don't we go ahead and try that.

That's what this script is. What we do is we just have the base URL and a variable, and then we curl down the list, that Apache generated index. We use grep, sed, awk, whatever else you want to use. And believe me, I'm sure there's probably at least a dozen people out there that could do this in maybe three letters or something, but I'm not the guy. But in the end, you've got this little script that will parse out those image names.

So, make this a little bit wider. We're going to run this script. So you can see the first thing that it was really, really very fast. It curled down that index file, and then it presented this. And you could type something like clear after this to clear that out, make it a little prettier.

And then it presents that list of images. So why don't we go ahead and choose number-- well, how about number nine? Zero. Zero. Yeah, number zero. Like I said, there's lots of people that could have done this a lot better. And there we go. It went ahead and mounted the image that I selected.

So in just, you know, what is that, a dozen lines of code, you've created this, you, the clever IT guy, or girl, has, you've created this nice little script that will read a dynamically generated list of disk images and monitor for the end user. So now that we've got this script fully functional in the command line environment, we're going to go ahead and go over to Project Builder. And, oh, look at that, there's already a project made. So create a new project.

And we'll go ahead and just pick Apple Script Application and call it whatever. And in the interest of time, I've already got all the text entered. But it'll create this project for you. And the first thing we'll do is we'll go ahead and go into Interface Builder and mock up an interface.

Now, this is going to be a very basic application. I mean, the only thing that we're doing, we're presenting a list of images to the user, and they're going to pick an image, and they want to mine it. So we really only need a couple interface items here. I've got a table. Where's my inspector? Tools, thank you. It's on by default in mine.

We'll go into the inspector and we'll give our table a name, call it the images, or that's the view, and then the table. And then we've got just this other button. We'll call it mount image, and when this button is clicked, we want it to do something in this script right here. So we attach some functionality to the clicked handler in the application Apple script. So this is really all there is to mocking up this interface, just a table view and a button.

and take a look at the script. Now, when you click on that checkbox in Interface Builder that attaches that unclicked handler to that button, it automatically generates some handlers inside of your Apple script. So the first thing that we're going to do is, instead of having to have the user actually do something to generate that list, I just want it generated automatically as soon as the application is launched. So we're going to use the onAwakeFromNib handler, and what it's going to do, it'll create... How about we just do this? Is that better? Okay, it's not too important. I'm going to pretty much talk you through it.

So we're going to dynamically generate the data source. It's just a detail. But then I've got basically two functions, this extractImageNames function and then the populateTable function. So the extractImageNames function is going to... Use the do shell script command right here to curl down that dynamically generated index, and then do some various stuff to parse out the information.

Now, you can see here I used sed, but I also used some AppleScript to do some parsing. I honestly don't care. I'm not a hardcore AppleScript guy that says I'm going to use AppleScript and use do shell script as very little as possible. And I'm not a Unix guy that says, I'm going to use awk till the day I die. Use whatever works.

And I found out that, you know, you saw that item zero that was alt whatever. I could not figure out how to get that fixed, so I just decided to throw in some AppleScript and use that to help me do the parsing. So this is actually a very nice tool in that you can mix multiple environments to get the desired result. So in the end, I just return that list of images, and then we populate that table. So that's what happened on startup. Now I've got this unclicked handler.

And this is going to be very simple. The user will pick an item in that table. The un-click handler will determine the index of that item and then pull that whatever item that is out of the list of disk images, which is kept in a global variable. And then it will do shell script, HDIUtilMount, and that particular disk image. And then I provide some feedback, because you're working in this application and something's happening somewhere else. So I'm just going to throw up a dialogue there that says the image should now be mounted on your desktop.

So we'll go ahead and build and run this application. And wow, that was really fast. A lot faster than my PowerBook. So the first thing it did was it curled down that dynamically generated index page, parsed out that list, populates this table with that list of items, and now the user can pick an item.

And why don't we go ahead and pick this one? Click on an item, click on Mount Image. Image should now be mounted on your desktop. So that is all there is to it. So let's go ahead and go back to slides. Now you can get really fancy with this. and David That was a very, very simple example.

Bah. You can get very, very -- I don't know what happened to my image, but --

But you can get very, very fancy with this. We'll just open up the nib file. Oh, sorry, could you switch back to the demo machine? So like I said, you can get really fancy with this. You can create preferences.

Good grief, that's a really old version. And you can throw in lots of functionality and make something so fancy that it can clone one disk to another. That's one thing that I've done. But this is a great tool, and basically you can do just about anything if you use Apple's developer tools to put a GUI on your script, and you can really extend it to many other audiences. So with that, I think I'll go ahead and hand this back over to Skip.

Thank you. We've tried to make it fun, tried to present a wide range of information for system administrators coming from a lot of different areas. These are some more information. Obviously, a good place to start if you're brand new to the platform, got to read Inside Mac OS X System Overview. The UNIX Porting Guide is also an excellent place to start.

and Mike's team at Microsoft. The tech note that Mike mentioned, calling Apple script from an application, excellent. And Mike has offered the source code for the application he just demoed up on his website, and he'll keep that up there for some period of time. And there's the URL for that. Thank you, Mike.

Who to contact? Bringing over an application, some of the larger applications, any place you get hung up or stuck, that's exactly what developer relations is for. You can contact myself, I'm the server technology evangelist. Waqar Malik in developer technical support, that's exactly what they're there for. And Mike Bombich has even relented to be contacted directly as well.

Kevin Boyd at the University of Michigan, the Mac OS X Deployment Coordinator, should you wish to talk to him. It's been a good week for you, Mish, already, I think. Radman D. and Fugu were both honored at the Apple Design Awards. He's also a member of the rsyncx development team.

Roadmap. Obviously, some of these sessions have already happened, so be sure to check them out on the DVDs or Apple Tools for the UNIX Developer, Introduction to the Tools Suite, GCC, and Debugging. And then of course, I think, a wealth of information at macos10labs.org. Yes, and don't enter a space in that URL or you'll get a nasty surprise.

and obviously being an open source project, you can find the source code to [email protected]. and David Koehn. We're going to be doing a lot of AppleScript Studio sessions. Sal Segoia is going to deliver a session called AppleScript vs. Admins that's really free-wheeling. He's going to go into a lot more detail about how to take really fun things you never thought you could do with AppleScript, attaching very nice GUIs to command line tools. And with that, I'd like to open it up to Q&A.