Bashing at the Keyboard (part I)

The command line. The feared enemy of anyone who started using a computer after 1995 (ish). It’s got a bad reputation, and for day to day computer tasks it’s certainly not necessary. However, if you are a programmer or a systems administrator then you’ll benefit enormously from knowing how to get things done on a computer using only a keyboard and a terminal.

I’d better take a step back at this point, and define my terms. When a Linux system boots, you (probably) see a text mode screen showing lots of gobbledygook (people peering over my shoulder usually wittily opine “it’s like the Matrix”). That gobbledygook does have useful information, but I don’t want to burden you with that at present. Suffice it to say: what you’re seeing is all the background plumbing of your computer starting up. The same sort of thing happens on Windows, but you don’t see it happening, you just see a progress bar or some kind of animated spinning arrow.

This text appears on what is called the console. It’s a very simple screen and keyboard implementation provided to get you access to your system when all else fails. Once the boot is completed, a login prompt gets shown on the console, and you could login with your normal user and password. However, on a modern system what probably happens, before you get time to look at the login prompt, or type anything, is that the graphics environment starts up and shows you a graphical login prompt. Should you wish, you can return to the text mode console screen by pressing Ctrl-Alt-F1. To get back to the graphical login you can press Ctrl-Alt-F7 (sometimes F8, depending on your distribution; and actually the Ctrl is unnecessary when going from text to graphics, but don’t worry too much about that).

So; we can choose to log in graphically, or textually. Let’s do textually to start, just so you’ve got an idea of what you would see (this is what I see, yours will be similar, with the differences depending on what distribution you use).

Debian GNU/Linux squeeze/sid host tty1

host login: user
Password:

No mail.
user@host:~$

Your password doesn’t get echoed to the screen, for obvious reasons, and you get very little noise after logging in, you are simply given a command prompt, in this case “user@host:~$”. Remember that for now, and we’ll go back to the graphical login with Ctrl-Alt-F7.

Login as normal. Now, find in your application menu something like “Terminal”, “Console”, “gterm”, “xterm”, “rxvt”, “Konsole” — exactly what it’s called is dependent (as usual) on your distribution and your chosen graphical environment (GNOME or KDE probably) — I like xterm myself (and I’ll say xterm from now on, but whichever you pick is fine). These are all so-called “terminal” programs. What they do is provide a graphical equivalent of the console we’ve just seen. The name “terminal” is a holdover from the days when computing was done with one huge single computer, with a dumb terminal (basically a screen and keyboard with a long wire connecting them to the computer) on the users desk. These terminal programs are the modern day equivalent, you open one and it provides a screen and keyboard in a window. What you’ll see when you run it is a window with the following in it.

user@host:~$

This is, for all intents, exactly the same as the command prompt you got when you logged in on a console. Anything you can do in text mode, you can do in a graphical terminal supplied by xterm (et al).

It’s worth pointing out here that it is not xterm that is providing this prompt — it’s merely supplying a screen and keyboard for another program. Terminal programs, once they have started, then proceed to run another program that has its input and output redirected to use the window that the terminal program is providing. By default, they run a program called bash. It is of a class of programs called shells and is the most commonly used. bash is the program that has output this command prompt “user@host:~$”. In exactly the same way, when we logged in on the console we were logging in using a program called (unsurprisingly) login; which upon accepting the login credentials you give it runs a copy of bash as well. It should be no surprise then to see that we get an identical prompt in both cases.

Shells are programs that are used to run other programs. At first hearing, it sounds like a silly thing to want. However, it’s use is so implicit that often people don’t even notice that they’ve been using it. As an example: many people think that the task bar, explorer and start menu in Windows are Windows — when actually they are just a graphical shell, and a surprisingly small part of the operating system. Whatever graphical system you just used to find xterm is a graphical shell is simply one program that is used to start another. bash is a textual shell, but has the same job — it lets you start other programs on the system. Let’s run a few programs now in our shell to get the idea.

user@host:~$ ls -a
.  ..  .bash_history  .bash_profile  .bashrc
user@host:~$ cat .bash_profile
# include .bashrc if it exists
if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi

# set PATH so it includes user's private bin if it exists
if [ -d ~/bin ] ; then
    PATH=~/bin:"${PATH}"
fi

We ran a program called ls, which lists the contents of the current directory (the -a means list all files, including hidden files). Then we ran a program called cat, which reads a file and outputs it to the terminal — in this case, one of the bash startup files, .bash_profile. The startup files for bash are a list of commands that are run automatically when bash starts. They are pretty much entirely devoted to setting up a workable command line, and configuring bash to suit the user (the default versions are fine for you for now).

Notice what I said about that first command, that it lists the contents of the current directory. bash maintains the idea of a current directory, and whenever you run another program with it, it passes that current directory to it. If you’re here from an entirely Windows-based computer upbringing, the terms “directory” and “folder” are entirely synonymous. Let’s look again at the command prompt that bash has been giving us.

user@host:~$

This prompt is configurable, and your distribution might have picked something different, but this is a common default form. There are three parts to this, separated by three punctuation characters.

• “user” this is the username active in this session of bash — in this case, the username you logged in with.
• “@” is punctuation, separating the first two fields
• host is the name given to this computer by the system administrator during installation. If you are interested, it is simply read from the file /etc/hostname during boot.
• “:” is punctuation
• “~” is the current directory, with the notation that the special case that the user’s own home directory is shortened to ~. You can read that as /home/user. It is purely for brevity.
• “$” marks then end of the prompt, and the cursor is left after this ready for you to type your commands.

Now that we know what ~ means, let’s go somewhere else and see what happens to it.

user@host:~$ cd ..
user@host:/home$ cd /
user@host:/$ cd /etc
user@host:/etc$ cd init.d
user@host:/etc/init.d$ cd
user@host:~$

Key points to note:

• “cd” is a builtin bash command which means change directory. With no arguments, it defaults to changing to the current user’s home directory (which we see as “~” in the example above).
• “/” on its own is the root directory. If you are from a Windows background, you might be surprised at the lack of a drive letter, and the change of direction of the slash. You would be used to having multiple root directories on each drive, labelled “" rather than”/“, for example”C:>" would be your command prompt.
• “/” is also the directory separator. /etc/init.d is a directory called init.d inside a directory called etc which exists in the root directory.
• Notice the difference between an absolute path, which starts at the root directory (“/etc”) and a relative path which doesn’t (“init.d”).
• A relative path can specify “up a level” by giving the name “..”; in the example above “cd ..” is used to go up from /home/user to /home.

The guides I write will almost universally be using the command line for the examples. There is an advantage to the command line for guide writers in that it’s much easier to give repeatable instructions, and give sample output than with a graphical environment. Describing which buttons and in what sequence a set of operations should be performed just gets in the way of the information.

Another important advantage to becoming familiar with the command line is that you can administer a remote system with a program called ssh. ssh is short for secure shell. It’s power is most easily shown with an example.

user@host:/etc/init.d$ ssh someotherhost
The authenticity of host 'host (192.168.1.1)' can't be established.
RSA key fingerprint is 3c:71:ac:13:5f:f6:04:2b:a0:c7:2a:b5:56:4e:ce:fd.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'host,192.168.1.1' (RSA) to the list of known hosts.
Password: 

user@someotherhost:~$ 

This was the first connection, so we get a warning about recording a new host fingerprint; we won’t see this for subsequent connections, and the recorded fingerprint will be automatically compared with the remote fingerprint to prevent man-in-the-middle attacks. We supply a remote host to connect to, and are asked for a password. What has happened though? ssh has established an encrypted connection from our system (host) to a different system (someotherhost), that let us type in our password without the possibility that it could be captured by someone monitoring the network, and then over that authenticated, encrypted connection, ssh runs bash. The power of this is subtle: we have a command line from the remote machine — anything we can do on our local command line, we can now do on the remote command line. Supplying a command line is very low bandwidth, so this can be done over the worst of connections.

I use exactly this facility to look after my family’s computers, and to administer a VPS (virtual private server) I hire. Being able to use a command line, and hence a VPS gives me access (for a price comparable to simple web hosting services) to a very powerful machine, with lots of bandwidth and the ability to install whatever server software I might choose. If you rely on graphical interfaces, you are stuck with whatever your hosting provider feels like giving you both in services and in browser-based management interfaces.

If you want to do any programming on a Linux system, you will gain an enormous advantage by not being afraid of the command line (it’s almost a prerequisite in fact).

There is more to say about command lines; the above is nothing more than an introduction to the concept; and an explanation for where it is useful.