Excerpt: Critical Bash for BeOS Because BeOS attracts as many users from the desktop publishing and digital video crowds as it does from the geeky Unix universe, BeOS users tend to fall on all points of the spectrum when it comes to how they perceive the Terminal. On one end of the spectrum are users who tend to think visually, and interact with computers best when its options are laid out in a clean, visual interface. For some of these users, the command line represents a hell they had hoped to escape decades ago, and may in fact be the very reason they ditched their IBM PCs at the dawn of the Macintosh. Others who have come to computing in the past decade have been born and raised on the GUI, and have never had much cause to deal with the command line at all. On the other end of the spectrum are longtime Unix jocks (and a few DOS-heads looking to take their command-line skills to the next level) who twiddled enough cryptic commands to become hooked for life. Some of these users probably would never have become interested in BeOS to begin with if it hadn't included the deeply integrated Terminal environment. One of the amazing things about BeOS is the graceful way in which it legitimizes both of these perspectives by integrating a graceful GUI with a complete command-line interface (CLI). While some systems feel like their GUIs were slapped on top of the command shell as an afterthought (because they were), BeOS was born with two faces: The graphical and command-line interfaces are welded together seamlessly. Unlike Unix-based systems, you cannot boot BeOS into command-line-only mode. Nor can the graphical interface be booted without the assistance of the shell, as BeOS's startup sequence is governed by a series of bash shell scripts. Why does the shell offer power that the GUI can't match? Because of the "atomic" nature of a shell. Commands (atoms) can be strung together into customized "molecules." Think for a moment of the English language (or any language, for that matter). Every word represents a fraction of the world, and by virtue of grammar and syntax, we can string them together into sentences that have meaning: ideas, proclamations, questions, poems. To paraphrase the philosopher Wittgenstein, with language it is possible to express anything that lies within the bounds of language. Beyond that is the inexpressible, and whereof one cannot speak ... ah, let's not go there. Unix-ese isn't quite as philosophical as all that, but the idea here is the same. By employing a large collection of small, discrete commands and by stringing them together with a consistent and known syntax, you can make your computer sit up and do tricks the GUI can only dream about (of course, the GUI can also do things the CLI can't, like advanced image editing). Enough spiel, let's dig in. There are two things that come together when you use the Terminal: Unix-based command-line programs and tools. The shell, which provides the environment in which these tools operate. bash is the name of the particular flavor of shell that runs in a windowed BeOS application called the Terminal. The Terminal and bash don't have any kind of necessary connection--the Terminal is capable of running any kind of text-based application, even other shells ported from the Unix world, such as tcsh or zsh. However, bash is the shell that ships with BeOS and it's unlikely that you'll find a need to run an alternative shell, so we'll only cover bash here. While the command-line tools provided with BeOS live in /boot/beos/bin, you may also access them from /bin--a symlink in the root of your filesystem makes these two paths equivalent for purposes of compatibility with hard-coded paths built into some tools. About Open-Source Tools The Terminal is not Unix. Unix is an operating system, and BeOS is an operating system, but BeOS is not a Unix-based operating system. BeOS is, however, POSIX-compliant, just like Unix. That means that BeOS has built into it a core set of command structures that are agreed upon by international committee as a standard to provide a degree of interoperability between disparate operating systems. What this means to users is that if they've used one POSIX-compliant operating system, they can probably use another without much difficulty (at least the command-line part). It also means that programs can be ported from one platform to the other with minimal changes. Interestingly, Unix culture is heavily rooted in a tradition of free, open-source, POSIX-compliant software. Rather than trying to profit from every hour of coding time, Unix developers often build programs and then give them back to the community along with the source code. Under an agreement called the GNU (Gnu's Not Unix) general public license, users are free to use the program and redistribute it to others, as long as the source code and the GNU license travel along with it (or are provided on demand). The user can modify the source code and try to make the program better if they like, or even try to profit by selling the program along with their modifications--so long as they in turn distribute their modifications along with the code. In other words, no one can stop the buck at their own desk if they want to play in the open-source software community. This unique arrangement has a great name, too: copylefting. Most of the commands that run in BeOS's shell have been ported from Unix to BeOS under the GNU public license, and are copylefted. That's why you'll find the source code for most of the CLI programs on your system in an /optional directory when you install BeOS. There are some exceptions: A number of programs specific to BeOS are mixed in with the command binaries in /boot/beos/bin--these are not GNU or copylefted.