Shell tutorial part 1

From LXF Wiki

Revision as of 12:26, 28 May 2008; view current revision
←Older revision | Newer revision→


Shell secrets

PART 1 Marco Fioretti explains how to unleash all the power of the command line.


Get your command line news here For a general introduction to the command line, a complete source of example scripts, coding style advice, useful tricks, tutorials and much more is at [1] ( Another portal, [2] (, aims to become your one-stop command line shop. Back in the realm of printed paper, a very good tutorial is O’Reilly’s Learning the Bash Shell by C Newham and B Rosenblatt (now in its second edition, ISBN: 1-56592-347-2).

The Linux platform is becoming a stronger desktop solution day by day, and part of the reason for this is the commitment by distribution authors to provide an exclusively graphical user interface, from installation to upgrade. We shouldn’t forget, though, that the command line interface still exists. It may not be as pretty as a GUI but this alternative interface has flexibility, and there are many cases where it can save you a lot of time. For example, you can use the command line to save and rerun long sequences of commands, or create new ones to be executed en masse. The great thing about the command line is that you don’t have to be a guru to use it. Even end users can use it, and will find it useful and even fun to write commands this way. And why take the trouble? Well, unlike in a GUI, where you can only click the buttons that somebody else thought were needed, you can create your own commands and tailor your system. For example, have you ever wanted to issue multiple commands with as little clicking as possible? If so, welcome to the shell prompt. Or consider the boot process, which involves a chain of text commands executed in a well-defined order and can be greatly customised if you know how. In fact, there’s nothing to stop you from getting the best of both worlds. Once a script works on the command line, it can be easily bound to a GUI’s desktop icon or menu entry. Then in the event of an emergency you can call on your command line knowledge to stay in operation. What about disaster recovery with a GUI - where do you point and click if you need to reinstall the X server?

Inside the shell

All command-line typing happens inside what’s known in Unixland as a shell. This is both a programming language and a command interpreter, providing an interface to the operating system. Every shell has control flow structures, manipulates variables and can be modified to suit the environment in which programs run - but often they do this in slightly different ways. There are hundreds of shells available for Linux, but you might only have a handful of them installed. To find which ones are installed in your system, type the following command:

$ cat /etc/shells

Bash (Bourne-Again Shell, an adaptation of the original Bourne shell originally written by Stephen Bourne at AT&T) is the most common choice on Linux systems. Another popular one is csh (C Shell), with a syntax more similar to the C programming language. tcsh is an enhanced, backward-compatible version of csh. The reason why there is more than one solution for (apparently) the same problem is the usual one: different shells may have different licences, and each one is optimised for slightly different uses. Find out more online at, an in-depth discussion of these and other shell programs that was written before bash claimed dominance. Programs written in a shell language, or any other interpreted one, are normally called scripts. They are just plain text files containing sequences of commands. Scripts are loaded and executed by the interpreter line by line, just as if you were typing the same sequence of instructions at the prompt. More explicitly, there isn’t anything that you can place in a shell program that you can’t type at the shell prompt, and vice versa. Are scripts better or worse than normal, binary-compiled programs? No, just different. Binary programs are faster but take programs? No, just different. Binary programs are faster but take much more time to develop and test. Scripts are much quicker to write but normally run much slower. What is important, and to write but normally run much slower. What is important, and should be evaluated case by case, is that the total time spent writing and running the program is minimised. In practice, shell scripts are usually the best match for the custom programming skills and needs of home and small-office Linux users. Programs and keywords Software programs are specific binary files physically stored on the hard disk. As a command line-based programming language, every shell can launch them directly. Shells also have, however, a set of built-in keywords, or commands, not corresponding to any actual program. This can cause confusion