- Home
- Ed Hartnett
Learning Old School Linux Page 10
Learning Old School Linux Read online
Page 10
* * *
I could have answered my niece's question by saying I work in Emacs all day, but I don't think she would have understood that either. You have to work with it to understand what a great tool it is.
Emacs: The Only Program You Need
Remember Mr. Spock? He used to look into that primitive computer thing and pull out answers that saved Kirk's butt again and again. It was always an amazing demonstration of computing prowess. It can finally be revealed what Spock was running on the Enterprise's computers: emacs.
This explains Spock's facility with computers! It wasn't that he was Vulcan, it was because he was an emacs user!
What Is Emacs?
Emacs is a text editor, but saying emacs is a text editor is like saying the Pacific Ocean is wet. It is more than an editor—it is a super-editor, an über-editor. It's the one that all the other editors wish they could be, but know they never will be. It is the top-banana, the tip of the spear, the big enchilada. It is not just a text editor. It is the text editor.
The primary audience for text editors is the computer programmer. Computer programs, though ephemeral, expensive and exasperating, are the core of all our coolest technology. And, when it comes right down to it, they are text files. Emacs is ultimately about software development. And it is the best software development environment, by far, ever to be developed.
To say emacs has a loyal following is to dramatically understate the case. I've used emacs for the last 25 years, nearly every day. If you took it away and made me use another text editor instead, I would use it to write emacs from scratch, rather than go on without it. That's the kind of user loyalty Microsoft would kill for. But they will never get it, because they can never produce any software a tenth as good.
Where Did It Come From?
Emacs was the beginning of the free software movement. It was the first application released by FSF (www.fsf.org) (Free Software Foundation), the first free software application that soared to a big, fat mind share.
Back in the olden times, before X Window provided a desktop interface for Linux, emacs just used the technology of the day—ASCII terminals. However, with version 20 of emacs, the X Window graphical user interface was fully supported by emacs.
Getting Started
To get started with emacs, type "emacs" at the command prompt. You will get an emacs window.
The most important thing to know is how to use the so-called "meta" key. The meta key is like the Control key (or "Ctrl," as it is abbreviated on the keyboard). As with the Control key, you hold down the meta key while hitting another key. For example to hit Ctrl-x, (or C-x, as you will see it called in emacs documentation), you hold down the Control key, and hit the "x" key. To do meta-x (or M-x), you hold down the meta key, and then hit the "x" key.
The only problem, as quick readers will already have perceived, is that there is no "meta" key on their keyboard. This key existed on an early ASCII terminal that emacs was developed on, but it didn't catch on, and so now there are no keyboards with a meta key.
No matter; with emacs there is always a way. On most computers, the "Alt" key will function as a meta key for emacs, so M-x can be achieved by holding down the Alt key and hitting the "x." In case the Alt key doesn't work, you can use the escape key ("Esc"), but it a slightly different way. Instead of holding down Esc and hitting the "x", first hit the Esc, and then hit the "x."
Awesome for Programmers
Now, why would programmers put up with all this business of meta and control keys? What are the features that emacs offers that make it worth the trouble? They are far too many to list.
The first are the editing modes. If you open a file named program.c in emacs, you will be in something called C-mode. This gives you all kinds of commands for programming in the C language, and turns on formatting that looks good for C code. If you open program.f, you will get Fortran mode. If you open program.java, you will get Java mode, etc. Almost every existing programming language has its corresponding mode. And here's the neat thing: The same commands work for every language.
For example, the M-x comment-region command will turn a region of code into comment, even though every language uses different characters for comments. M-x indent-region will cause a bunch of code to have good indenting for whatever programming language you are working in. And there are many, many more.
Starting a Life of Productive Programming
Emacs can be a bit confusing to get started with. It's a serious power tool, and requires some dedication and effort to use properly. But give it a try—you won't regret it!
Using the Shell
In the days before graphical user interfaces, the command line shell was the way we interacted with computers. On Windows, the command line shell has been relegated to the DOS command window, but on Linux, the shell is alive and well. Many advanced users prefer shell interaction over GUIs because of the power, ease, and flexibility of the command line.
Coming Out of Your Shell
One of the great things about Linux is the variety of ways in which you can interact with the software. In some operating systems (and I will point no fingers!), there is only one way to get the job done. Functional, but boring. On Linux, it is never this simple and always more exciting.
Last week, I described some of the different graphical user interfaces that Linux users can enjoy, but the graphics in Linux are just a layer on top of a more basic command-line interface.
What's a Command-Line Interface?
Predating today's modern world of fancy graphics, the command-line interface hails from the old days—when men were men, and computers were the size of minivans. In those days, the so-called "smart" terminal was all the rage because it could achieve such amazing visual effects, like blinking text, different-colored text and even bold text. Programmers of that era were very close to the hardware. They often used the specs from the hardware manufacturer, and each type of machine had its very own operating system.
Back in the 1970s, a programmer named Ken Thompson was working on the development of a new operating system—one that, for the first time, was not written for any particular computing hardware, but rather was generalized, so that it could work on any hardware. As a metaphor, Ken imagined the hardware system as the yolk, with the system software as the egg whites, but there was something else needed—something between the egg and the user. Something to wrap around all of the system's functionality, and be all that the user needed to touch. That something is the shell. In 1971, Ken Thompson released the first version of his eponymous shell, and the Thompson shell was the basis for all succeeding UNIX command-line interfaces.
Pipes and Redirects: the Plumbing of UNIX Systems
One thing that the shell must do is allow the user to run programs on the machine. In fact, this is the main purpose of the shell. If you have a program called "trek," then the user must be able to type "trek" somewhere, to launch the program—in this case, a classic Star Trek game.
But the Thompson shell did more than this. It allowed users to send a file into a command, just as if all the lines in the file had been typed on the keyboard. It allowed the output of a command to be saved or appended to a file. And it allowed the output of one command to become the input of another.
With these capabilities, the shell turned into a powerful tool for assembling complex command sequences. Simple tools, used in complex combinations, can do sophisticated data processing. This is the basis for the success of the UNIX operating system.
Meeting the Families
In the UNIX world, there are two families of command-line interface, both derived from the original Thompson shell. One is called the Bourne shell (sh), and the other, the C shell (csh). From these two early shells, a whole coral reef of free software has been built, and many variants exist that improve on these two shells. Some of the choices now include the TENEX C shell (tcsh), the Bourne Again shell (bash), the Korn shell (ksh), and the Z-shell (zsh). Each of these variants of the shell offers its
own set of features, its own way of helping users automate their common tasks and string together different UNIX tools to do one complex job.
In spite of all these alternatives, there are still some diehards out there who stick with the original shells out of some sort of stubborn tribute to the past. We all can respect the past, but that doesn't mean we walk around with wigs and tri-corner hats. Sometimes the past has been improved upon, and that's the case with UNIX shells. (I'm a bash man, myself.)
Now You're Speaking My Language!
After typing in a complex series of commands, you long for a way to automate the tedium of doing so again. And this leads, quite naturally, to needing a way to generalize and pass parameters to the commands, so they can be adapted for various circumstances.
The shells that came after the Thompson shell started to include the features of procedural programming languages—variables, branches and loops. A variable is a named area of memory that can store a value that changes (i.e., varies). The branch is an if-then decision. If some condition is true, then execute some code; otherwise, execute some different code. The loop is a way of repeating code as many times as needed.
With variables, branches and loops, procedural programming becomes possible. This allows the automation of complicated and tedious tasks, and allows the programmer to encode ways for the computer to do the "right thing" under various circumstances.
There are many existing examples of shell programming, and many existing systems that are based, in part, on sophisticated shell script programming. Professional programmers will prefer to use more feature-rich languages (like Java) for really complicated programs, or languages that make more efficient use of the computer for better performance (like C). But any programming task can also be performed with the various shell languages, and sometimes it's quicker and more convenient to do so.
Programs for the shell are usually called scripts, and shell scripts can quickly become indispensable to the computer power user.
The DOS Shell: A Hastily Hacked Toy
One of my college buddies has a great term for the kind of watered-down math classes that business majors take. He called it "let's pretend math." The same term can be applied to the Windows version of the shell, the DOS shell. Reportedly, it was written by Bill Gates on a flight to meet the IBM engineers who would be using it on the new (at the time) IBM PC. I don't know if the story is true, but I have little trouble believing it. Any UNIX user who encounters the emasculated features of the DOS shell will have no trouble believing that it was written on an airplane, with all the distractions and limitations that might imply. The DOS shell is a "let's pretend" shell, with little of the power and elegance of the UNIX shells, which are so shamelessly copied. The DOS shell is an inferior knock-off.
The Shell Today
These days, just about everything on a Linux box can be done through whichever GUI you are using, but that doesn't make the command line useless—it is a tool for experts. It allows you to run commands with a powerful and terse syntax, and provides a wide variety of tools to help you customize your interaction with the computer.
The shell is still there, just as it always has been, waiting to provide a powerful interface to the user who is willing to take the time to get to know it.
Fun With Bash Prompts
Every command-line interface must have some sort of prompt string—something that is printed out on the terminal to indicate that it is your turn to type—to tell the computer what to do. You then issue a command, and when it is complete, the prompt again appears to let you know that the computer is ready for more input.
When I start my bash shell, I see: ~> .
This is my directory ("~" means home directory), and then an angle-bracket and a space indicates the end of the prompt. (The space is important; without the space, the command line looks very crowded and ugly.)
As with most everything in Linux, this can be customized by the user. You change your prompt by setting the environment variable PS1, and there are many neat things you can do to make the prompt more useful and interesting.
Setting an Environment Variable
To set an environment variable in bash, use the export command. Once you set the PS1 variable, the command line immediately changes.
~> export PS1='what is your command human? '
what is your command human?