|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
by Chris Herborth
| Section 1 |
What Is Scripting |
| Section 2 |
Application Scripting Languages for BeOS |
Section 3 |
Setting Up a Script |
| Section 4 |
Shell Scripting 101 |
| Section 5 |
Really Advanced Shell Use |
| Section 6 |
BeOS Application Scripting |
| Section 7 |
Making Your Scripts Run from the Tracker |
|
|||||||||||||
| As we said above, you can use any language to write scripts in BeOS. For most of the examples in this chapter, however, we'll be using the bash shell and the command-line tool hey to work with application scripting. The biggest advantage to using bash for your scripts is that you can easily share them with any other BeOS user--bash comes built into every copy of BeOS. |
What makes a normal text file full of commands a shell script? Well, there are two parts: the magic cookie and the x bit.
| The "magic cookie" in a shell script isn't the same kind of cookie used on the Internet; it's just an easily recognizable sequence that the system uses to indicate an executable script. It won't follow your every move, store your credit card information, or fill your disk with mysterious files from who-knows-where. |
What If Someone Installed Python Somewhere Else?The default location for Python is /boot/home/config/bin, but some people like to rearrange things the way they want them. If Python isn't at the default location, your script will need to find it. You can use a command named env (which stands for "environment") to will search for something for you: #! /bin/env python print "hello world" Now env will search for Python and tell it to run this script. This script will run on any system that has Python installed, as long as it's installed in one of the system's executable search paths (see Chapter 6 for more information about the PATH environment variable, which controls your search path). Keeping hard-coded paths out of your scripts is a very good idea, especially if you intend to distribute your scripts. Nobody will ever have a system set up exactly like yours. The usual way to let a user customize a script is to read your paths from command-line arguments, environment variables, or a config file. Some of the books mentioned in Chapter 6's Learning More section will tell you all you need to know about doing this sort of thing. |
#! /bin/sh
#
# Print a friendly message:
echo hello world
That first line is the magic cookie. Normally, when the shell sees a "#" character, it ignores the rest of the line; this lets you put explanatory notes--or "comments"-- in your shell scripts. If the second character of a comment in the first line of a shell script is "!", it isn't a normal comment anymore--it tells the shell that this is a script of some sort.
The rest of the magic cookie line tells the script where to find the program that will interpret the commands in the script. The sample script is a shell script, and will be run by the shell, which lives at /bin/sh.
You also need a magic cookie line for any other scripts that need a scripting interpreter. You would set these in the same way, substituting the appropriate script interpreter for /bin/sh.
For example, this sample script needs to run in the Python interpreter:
#! /boot/home/config/bin/python
#
# Print a friendly message:
print "hello world"
Comments that start with #! anywhere in the file other than on the first line are just normal comments. Magic cookies can only appear on the first line of a shell script.
The x bit has nothing to do with Mulder and Scully. As you'll recall from Chapter 6, The Terminal, every file has some Unix-style permission bits associated with it, indicating who can read the file, write to it, and so on. One of these bits is the x bit, which indicates if file can be executed.
To set the x bit on your shell script, use the chmod command:
$ chmod +x script_name
Why not try it now? Open up StyledEdit and create a file named hello_script; type our sample shell script and save it:
#! /bin/sh
#
# Print a friendly message:
echo hello world
Now open a Terminal, find hello_script, and check its permissions:
$ ls -l hello_script
You should see something like this:
-rw-r--r-- 1 chrish techies 28 Aug 10 16:58 hello_script
Now set its x bit:
$ chmod +x hello_script
If you check the file's permissions again, you should see that the x bit is now set:
$ ls -l hello_script
-rwxr-xr-x 1 chrish techies 28 Aug 10 16:58 hello_script
You can now run it just by typing its name:
$ hello_script
If nothing happens or you get an error message, either permissions haven't been set correctly, or the script is not in one of the directories in your PATH. If the shell prints:
hello world
then congratulations--you've just written a program for BeOS!
Say you've written a really great shell script that does something useful (we'll start working on that soon!), and you'd like to keep it around and use it whenever you need it. Do you always have to work in the directory where the script is located?
Nope! As we've seen, the system treats shell scripts as normal executable programs (assuming they've got the right magic cookie and x bit). The PATH environment variable (see Chapter 6, The Terminal) helps the shell find programs, and there's a standard directory for your own custom programs: /boot/home/config/bin. This directory is always in the PATH, so if you want to reuse your super wonder script, copy or move it there:
$ cp super_wonder_script ~/config/bin
| Remember, in the shell you can use ~ as a shortcut for your home directory, which is set to /boot/home. Putting your scripts in /boot/home/config/bin lets you use them no matter where you are in the Terminal. |
Once your scripts are in this folder, which is in the system PATH, you can use them from any other location in your filesystem.
| There's a handy program on BeWare called xicon that helps you run scripts from the Tracker; we'll talk about it in Making Your Scripts Run from the Tracker, later in this chapter. |
| << previous |
|
next >> |
![]() |
![]() |
Please direct technical questions about this site to webmaster@peachpit.com.
Copyright © 1999 Peachpit Press and the respective authors.