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 In this section: Making Your Scripts Run from the Tracker    Installing xicon       Testing xicon    Using xicon    Enhancing xicon Scripts Learning More Making Your Scripts Run from the Tracker You don't always want to run a script from a Terminal window; sometimes you just want to drag and drop a file onto a script from the Tracker and have it do something, or create a double-clickable custom icon you can store on your Desktop to launch your own scripts. Unfortunately, this may not work the way you'd expect; you won't see any output from the script, and the script probably won't be able to find your files. Even if it does produce output, it'll probably put it somewhere strange. The shell has the "current working directory" concept (see Chapter 6, The Terminal), and shell scripts often depend on this to function properly. Without a Terminal to run in, the script's output (including any error messages) will disappear, and nothing will seem to happen. Luckily, BeOS developer Pete Goodeve has stepped up to help us out with this problem with his xicon utility (available on BeWare). xicon lets you run scripts from Tracker icons as if they were regular applications. It automatically opens a Terminal window for the script to run in so you can see the output and interact with it if necessary. You can also drag and drop other icons onto the script's icon in the Tracker, and the script will then run with the dragged items as arguments. With the help of magic cookies (covered earlier in the Magic Cookies section), xicon can run any kind of script: shell, Perl, Python, Tcl, REXX...whichever language you prefer. As with any script, the magic cookie will control the script interpreter that xicon uses. Installing xicon Download xicon from BeWare (both PowerPC and x86 flavors are available), unpack the archive, open the PROGRAM folder in the new xicon folder, and move the appropriate version of xicon to your /boot/home/config/bin directory. To make sure the Registrar (see Chapter 5, Files and the Tracker) knows about the script filetypes used by xicon, you can run the mimeset command on the newly installed xicon program: mimeset -f -all /boot/home/config/bin/xicon This'll make things a little smoother, and your special xicon scripts will have nice icons in the Tracker. You should delete the unused binary (x86 if you're running on a PowerPC system, or vice versa) right now. If you drop it in the Trash, be sure to empty the Trash right away. A small bug in the Tracker considers BeOS binaries from the other architecture to be valid executables, and you could end up trying to run the x86 version of xicon on your PowerPC (or the PowerPC version on your x86). As you can imagine, this doesn't work out very well, and you'll get an error message ("Not an executable.") from the Tracker. Testing xicon To make sure you've installed xicon properly, try double-clicking one of the sample scripts that came in the archive. If you run the test example, you should see a Terminal window like the one in Figure 8.8 pop up. (The directory displayed by test will probably be different and show you the full path to the xicon folder.) Figure 8 xicon's test example You can also drag and drop something onto test to get an ls -l listing for that file, its filetype, and a listing of its file attributes, as shown in Figure 8.9. Figure 9 Dropping something onto xicon's test example Using xicon To actually use xicon with a script, all you have to do is drop the script onto the convert to xicon script file that comes with the xicon archive. This does several helpful things: Makes the script executable (sets the x bit) Changes the script's filetype to text/x-script.xicon Sets the script's preferred application to xicon Tells the Tracker to let the script accept any type of file using drag and drop What xicon Really Does To do this yourself on a script named my_script, you'd execute a series of commands like this in a Terminal window: $ chmod +x my_script $ settype -t text/x-script.xicon my_script $ addattr BEOS:PREF_APP application/x-xicon my_script $ rmattr BEOS:FILE_TYPES my_script (If the script doesn't have any supported filetypes, you'll get an error for that last command. That's OK--we're just making sure the script can accept any kind of file.) Now when you drop a file on the script, a Terminal window will pop up, the script will run, then the Terminal window will vanish. Enhancing xicon Scripts You don't always want the Terminal to close as soon as the script is done; sometimes it's nice to see what happened, and windows that pop up and vanish quickly tend to make people think their system is about to crash. Not to mention the fact that windows flashing in and out of existence are annoying. So how can you keep the window from closing when it's running from xicon? The flipside of this question is, how can you tell when you're running from xicon? When your shell script is launched by the Tracker using xicon, the FOLDER_PATH environment variable is set to the directory where the script lives. If your FOLDER_PATH isn't set to anything, you're running from a normal command line, but if it is, you're running in one of these temporary Terminal windows that xicon opens for you. The window will stick around if your script is asking for input from the user (such as the test script, above, which asks you to "Type a return to continue"). A simple way to make sure this happens is to add these lines to the end of your script: #! /bin/sh ... if [ -n "$FOLDER_PATH" ] ; then read fi The if statement is checking to see if the FOLDER_PATH environment variable is set to anything. If it is, we use the read statement to wait until the user hits the Enter key. To see how this works, take your test_script from earlier in the chapter: #! /bin/sh echo "Hello world"   Figure 8.10 xicon's special script icon and drop it on the convert to xicon script icon in the xicon folder. The test script's icon should change to a document with a big red plus sign on it and what looks like a grey Terminal window inside. Now if you double-click test_script from the Tracker it'll run in a window, thanks to xicon. If you didn't see anything, your system is too fast (I'll bet you never thought you'd hear that!) and the window is vanishing immediately. Change the test_script to include the if statement: #! /bin/sh # Print our message of peace. echo "hello world" # Now, if FOLDER_PATH is set to something, wait for the user # to press Enter. if [ -n "$FOLDER_PATH" ] ; then read fi If your favorite editor didn't preserve the file's type (maybe it changed it to a plain text file, and the icon looks like a plain old document now), drop it on the convert to xicon script icon again. When you double-click the new test_script, you'll get a Terminal window with your friendly message in it. The window will stick around until you close it or you hit the Enter key. Figure 8.11 test_script running in its own Terminal, courtesy of xicon Your scripts can use this FOLDER_PATH environment variable to help find other files or to save some output in the directory containing the script. Use something like #! /bin/sh if [ -n "$FOLDER_PATH" ] ; then cd "$FOLDER_PATH" fi ... at the start of your script to change into the script's directory before you do anything else. Learning More If you're interested in learning more about writing shell scripts, be sure to check out some of the books mentioned in the Learning More section of Chapter 6, The Terminal (especially Learning the Bash Shell and Unix in a Nutshell). There's also a wealth of shell scripts available on the Internet, although not many are aimed at the beginner. TrackerBase, by Scot Hacker (you may have heard of him), is full of great examples for scripting newbies; you can find TrackerBase on BeWare or at Scot's BeOS software archive at http://www.birdhouse.org/beos/software/. Lurking around Usenet groups like comp.unix.shell and comp.sys.be.help isn't a bad idea either. To get more bang for your buck with BeOS GUI application scripting, keep an eye out for scripting languages that support BeOS messaging (in BeWare's Languages section), read the documentation that comes with your applications, and encourage developers to support scripting in their applications. Again, comp.sys.be.help will be a good place to ask questions and share scripting experiences, and so will the beusertalk mailing list (http://www.be.com/aboutbe/mailinglists.html). You might also find some useful tidbits (including heymodule, which brings BeOS application scripting to Python) on my Web site, http://www.beoscentral.com/home/chrish/Be/. There's a lot more there than just heymodule; look for a large BeOS community page listing BeOS developers, useful information, links, and lots of software. << previous ^ top ^