Author Michael Stutz said he has never been satisfied with existing resources for learning about Linux, which is why he wrote The Linux Cookbook. Stutz aims his book at beginners and more experienced users by presenting lessons in a format modeled after a culinary cookbook. In this interview, Stutz discusses shells and graphical versus command-line interfaces -- and why sometimes, in computers, a word is worth a thousand pictures.
For a newcomer to Linux, or someone who is mainly familiar with Windows, could you explain what the shell is and what it does?
Michael Stutz: The shell is a program that provides an interface between the user and the operating system -- it handles your input, controls the execution of other programs and coordinates their output. Those are the generic requirements. In practice, shells can be very robust environments. Most Linux distributions come with several different shells preinstalled that you can pick from. And you can run all kinds of interfaces -- graphical and otherwise -- on top of a shell, but the shell is always there at the base, mediating between you and the operating system. The shell is one of the fundamental components of the Unix operating system, of which Linux is a popular modern-day variety.
There's a good analogy for users of Windows, because I've never thought of Microsoft Windows as anything but an incompatible clone of Unix. It started out as DOS, which was a grossly stunted clone of the shell, made to run on the single-user microcomputers of the time. Then the Windows program was written as an interface to run on top of DOS, much like the X Window System in Unix.
Learning the language of the command line is recommended, whether it's done in the window of a GUI or not, because without it you can only point at pictures.
Is one shell better than another for those starting out with Linux?
Stutz: There are many different shells for Linux -- as many as there are editors. If you're new, stick with the Bash shell, because it's so widespread and it's the default on most systems. Then once you're good at it, if you have a need to go further with the shell, have a look at the others to see if there's one you like better.
How necessary is it for a Linux user or administrator to be comfortable working with the shell or typing at the command line?
Stutz: A Linux administrator must be more than just comfortable with the shell or typing at the command line -- he must be fluent in its use, or he's incompetent for the job.
It'd be like hiring someone for a customer service position who can't speak the language of the customers -- a disaster for the customers, and sooner or later for the company as well.
Aren't most distributions now built to be run from a graphical user interface (GUI)?
Stutz: There's a kind of popular misconception about computers that says that the command-line interface (CLI) was obsoleted somewhere around 1991 (or 1984, if you're an Apple user) by the "advanced" GUI, therefore the shell is some kind of primitive, outdated mode of operation.
But the reality is actually the opposite: The eschewing of the word for the visual is the impulse to primitivism, which Jacques Barzun shows in its various manifestations in From Dawn to Decadence: 1500 to the Present: 500 Years of Western Cultural Life. It's nothing new. GUIs, in fact, are actually as old as the command line. Almost since the beginning, Linux distributions have been set up to run with a graphical windowing interface, but they all still run shells. GUIs are often run on top of a shell -- and to do anything useful from inside the GUI, you've got to run another shell inside a window!
The main utility of a GUI is that you can run multiple shells and other programs in it, and display them all at once on the screen, each in a window of its own. It's actually a very old-fashioned idea. There's nothing new about it -- as with CLI, these windowing GUIs go back four decades. And contrary to this popular misconception, the two are not dueling methods of interface. What people call a GUI can never supplant the shell language. No matter how good a GUI is, it can really only accompany a shell -- it's only an added interface. (There's no law that says that shells cannot be graphical, either -- it's just not practical to write them that way in today's computing environment.)
In a practical sense, why should administrators learn to use the command line?
Stutz: Learning the language of the command line is recommended, whether it's done in the window of a GUI or not, because without it you can only point at pictures -- the equivalent of being stuck in a foreign land with only a pidgin vernacular. If you can't speak the language, you're going to have trouble expressing complex or original ideas. You'll even have trouble conceptualizing ideas. It will hold you back.
Both the windowed GUI and the language of the command line have improved a lot since the 1960s, to be sure, but they have not essentially changed. Nor has there been, in all these intervening decades, any innovation in the computer interface so great as these. We're all still tapping away at keyboards, clicking mouse buttons and peering into screens.
And I doubt that any real advance is possible over the command line to go beyond the word, because while there are other forms of expression -- such as music and the visual arts -- none is as versatile as the word.
The concept of using reserved characters seems tricky to me. What are they and how do they work in the command line?
Stutz: When you type something at the command line, the shell will pass it on to the system verbatim. The shell doesn't fiddle with it, doesn't even look at it, so to speak.
But many shells have their own set of reserved characters, which are characters that have a special meaning in that shell: for example, the single and double quote characters are used by the shell to quote strings -- if you want to type a command to reference a file named JOE'S, with the single-quote mark in the name of the file itself, you'll type it as JOE'S so that the shell knows that the single-quote character is part of the file and not the beginning of a quotation.
Do you have any tips for managing jobs? How does an administrator know which jobs should run in the foreground or the background?
Stutz: Most of your interactive work you'll do right in the foreground. Common sense will tell you if you need to run something in the background. You can also schedule jobs, which is useful -- you can schedule jobs to run at off-peak hours, or schedule to have jobs start at particular times.
Passing off jobs to the background is something that administrators do all the time in enterprise environments. For instance, you might wish to perform some lengthy file searches, jobs that would take minutes or even hours -- you're not going to run that command, and then sit at the keys until it's done. 'Sorry, boss, the computer's busy!'
Could you provide an illustration of how running various jobs would work in a real-world enterprise IT environment?
Stutz: You just make it a background job. The computer is doing it, but it's happening off in the background someplace and not hogging up your terminal. You're free to run other commands and do other things while the background job is processing.
For someone who wants to learn more about running Linux, how would you recommend that they educate themselves?
Stutz: Computers are just machines, and the best method to learn about their operation is the same as with any other machine: Get as much hands-on experience as you can, preferably starting out under the guidance of someone who knows his stuff. Learn from your mistakes and keep learning. As with anything else in life, when you find you've stopped making mistakes, you know that something's wrong. You know that you've stopped learning.
This is a very relevant question, because it cuts right to the heart of what made me write this book. I have never been satisfied with existing resources, especially textbooks aimed at educating from the very beginning level up. I wrote The Linux Cookbook to fill that gap.
Michael Stutz has used Linux exclusively for over a decade. He was the first to apply the open source methodology of Linux to non-software works, and was one of the first reporters to cover Linux and the free software movement in the mainstream press. His "Living Linux" column runs on the O'Reilly Network.