BeOS Application Scripting

Making Your Scripts Run from the Tracker

In this section:

What Is Scripting?

In Chapter 6 we introduced you to the GNU bash shell that you'll find in BeOS's Terminal window. With any luck, you've been spending a few minutes here and there playing with the shell, experimenting and getting an idea of the things you can do from a command line, (or maybe you were already familiar with using a shell).

If you were frightened by Chapter 6, you might want to postpone reading this chapter until you've gotten familiar with the shell and are ready to make it even more useful.

What Is Scripting?

Good question! These days, there's a fine line (or no line) between "scripting" and "programming."

Wait, don't run away! Yes, I just said the "p" word, but don't let that scare you. You don't need a degree in computer science to write useful scripts--in fact, if you've used one of the many huge, bloated software packages available for other platforms, you've probably already done some "programming" in the form of macros. Feel free to give yourself a pat on the back if you've just learned that you're a programmer.

People spend hours of otherwise useful time arguing about the definition of "scripting" versus "programming" languages. By the end of the argument, the combatants are down to discussing details that nobody cares about, and they still don't have a good definition; it usually has more to do with what you're using the language for at the time. However, many people say, and we're going to assume in this chapter, that a scripting language is about controlling other applications, not programming a new application. (Unless that new application is for controlling other applications...you should be starting to see how annoying this discussion gets.)

When we talk about "scripting" in BeOS, we're usually talking about two different (but sometimes related) things: shell scripts and BeOS application scripting.

Building Blocks Even though scripting doesn't require programming skills, learning to write scripts can be a great way to get a handle on basic concepts that you can use later on if you do decide to learn to program!

Shell Scripts, Application Scripts, What's the Diff?

If you're new to the whole concept of scripting, it may be a little tough at first to sort out the difference between shell scripting and application scripting, and to understand why we've organized this chapter the way we have. These two concepts are both completely separate and tightly linked. As you learned in Chapter 6, The Terminal, there are hundreds of commands available to the bash shell. As you'll learn in this chapter, you can string these commands together and save them in text files to automate anything you do from the shell. That's shell scripting--automating your operating system with command-line tools.

"Application scripting" refers to controlling your BeOS applications, both third-party applications and those that came with your system. The BeOS architecture makes this powerful functionality available for you with any application in your system--you don't have to rely on vendor-specific macro languages. All you need to script BeOS applications is the ability to send those applications system messages, called BMessages, and the ability to find out which messages a given application will respond to.

As you'll learn in this chapter, the ability to send system messages will eventually be built into most of the major scripting languages available for BeOS, which will let you use any language to create application scripts for BeOS. Until that time, though, we need to use a mini-language specifically designed to send BeOS system messages, and control that language from within scripts. That package is a command-line utility called hey.

In this chapter, we're going to take a brief look at the principles behind both types of scripting, and then dig more deeply into each one. We'll use the shell and simple shell scripts to demonstrate the use of hey and give you a taste of the power of BeOS application scripting. Shell scripting is a mighty powerful tool in its own right, and combined or extended with BeOS-specific scripting opportunities, is a veritable Swiss Army knife capable of making your computer do what it's supposed to do: make your life easier and take care of the grunt work on your behalf.

When it comes to controlling a GUI application from the shell with hey, the shell is just another programming language. hey gives the shell the ability to send messages to GUI applications, and that's the only requirement to make any programming or scripting language into a BeOS application scripting dynamo.

Let me say that again so you don't miss it: There's nothing special about the shell and hey. Any programming language that can send messages will be able to remotely control GUI applications, and thus will be a candidate for BeOS application scripting.

Shell Scripts

A "shell script" is just a text file (usually with a filetype of text/plain or text/x-script.sh) that's been marked as an executable with the chmod command. (Don't worry, we'll show you how to do this just a little later.) Inside this text file will be one or more shell commands--normal commands that you could just type into the Terminal at the command line. For example, a really simple (and somewhat pointless) shell script to print "hello world" could look like this:

#! /bin/sh
#
# Print a friendly message:

echo hello world

Wait a minute, what's that crap at the beginning? Well, it's magic, and we'll talk about it in detail in the Magic Cookies section.

Most shell scripts are a lot more complicated than that; if they were that simple, you'd just type the commands into the shell. Shell scripts are a way of sticking a sequence of commands together in a convenient package; this lets you reuse long sequences of commands, to do almost anything.

BeOS Application Scripting

So, if a shell script is just a bunch of shell commands, what's BeOS application scripting? It's certainly got a more impressive name. To explain it in more detail, I've got to wax poetic and discuss how some other operating systems work, how applications communicate in BeOS, and some other details.

Messages As mentioned earlier in this chapter and elsewhere in this book, BeOS does much of its work by sending small, well-defined messages (BMessages) between the various running applications and system servers. This helps distribute the workload, makes the system stable (by keeping the all-important servers separate from the user's applications), and generally makes life better for everyone running BeOS.

For example, the messages sent between each application and the system's Application Server cause the app_server to put windows on your screen, redraw parts of your windows (also known as "views"), and do various other useful things. In return, the app_server sends messages to the application every time the user presses a key, clicks the mouse, opens a menu, or closes a window.

Wouldn't it be useful if you could send commands to your applications just like the app_server does? In other words, imagine that you could send messages to an application telling it to close a window, open a file, make a menu selection, or do anything you would normally do if you were using the application directly--you'd be able to automate your applications and make them do repetitive, boring tasks without having to sit there and do them yourself.

That's exactly what application scripting is! Every single application running on BeOS can accept and respond to "suites" of scripting commands, whether or not the programmer added special code to handle this. It's all automatic.

In BeOS, application scripting is done by sending messages to running applications. If necessary, they can send back information in a reply message.

Scripting Wars

Every now and then, a seemingly innocent question pops up on the various BeOS email lists: "Why doesn't BeOS come with a native scripting language of its own?"

Usually this is accompanied by some pining for the poster's favorite operating system, usually OS/2 or the Amiga, both of which happen to have the REXX scripting language built in. Many applications for both OSs could be scripted using REXX, and developers could distribute REXX programs with their applications as examples of their scripting support, similar to the way MacOS applications can be controlled with AppleScript, the way Windows applications can be controlled with VisualBASIC, and the way some UNIX applications can be controlled with Tcl.

This discussion almost instantly degenerates into an argument about the merits of various scripting languages and operating systems, and is immediately banned from the mailing list because it has nothing to do with the list's usual subject (such as using BeOS or developing BeOS applications).

Everyone is tired of these Scripting Wars; all of the list old-timers have either given up trying to convert everyone else to The One True Scripting Language, or they've come around to believing that BeOS is doing the Right Thing.

Which, of course, it is. By using the standard message-passing objects and functions already present in BeOS, you can use any scripting or programming language to control any BeOS application. The language and the application don't have to be specially designed to talk to each other, and the user can use whatever language they feel comfortable with, as long as it can send messages.

It's hard to argue against this sort of flexibility, though some people try. Usually they complain about not having a standard scripting language, which means that they have to write their sample scripts in all languages or they can't distribute any sample scripts at all because they have no way of knowing what scripting language the user is going to have installed.

But what these detractors fail to understand is that BeOS does come with a standard scripting language: the bash shell!

This doesn't mean that bash is the only scripting language that you can use with BeOS; again, you can use any language that lets you send messages to running applications.