|
Every once in while you get to hear the litany that
'the command line' is 'out of date', 'arcane' and so on. And that people
and operating systems should get rid off it.
The truth is: you can use Linux without knowing
anything about the shell. You can boot your system directly into X and shut
it down from there. You can use the Mandrake Control Center and Webmin to
configure all and every aspect of your system.
It is my conviction, however, that using Linux without
the shell is like driving your car in first gear only. Sure, it's easier
at a first glance and you get where you want most of the time. But it's slow
and takes the fun out of driving.
And that's it: the command line is fun. It's like the biggest collection
of building blocks you've ever seen. And these blocks can do the most amazing
things and what's more, you can make them cooperate, thus achieving highly
complex tasks within a few lines. This is because in Unix the shell isn't
just a simple command interpreter like DOS in Windows, but a fully fledged
programming environment.
That isn't to say it is easy learning your ways around
the shell. Well, it's learning, so what do you expect? ;-) But believe me
that it can be highly rewarding. And you will be regarded as a Unix wizard
by most outsiders in a rather short period of time *grin*.
In order to get some ideas what a shell is anyway, a
little background knowledge might be useful
 section index  top
Back in the days when Unix was born, the now dominant
breed of 'personal computers' was completely unknown. The machines then referred
to as 'computers' were bulky brutes using tapes and magnetic memory (hence
the term 'core' for system memory). With the PDP-11 by DEC (now Compaq)
introduced in 1970, a 'small' (thus called 'mini') and rather cheap computer
appeared on the market and turned almost instantly into a big hit with universities,
most of which were for the first time able to buy a computer (the PDP-11
was a real bargain at 10000$).
The operating systems for these machines were written
in assembler, machine code, thus being highly efficient but also being totally
and utterly unportable. Each computer vendor sold his operating system along
with his machines.
The awkwardness of this situation was soon realized and attempts were started
to create an operating system which could be run on more than one brand of
machines. 1969 Ken Thompson wrote the first code of what was to become known
as Unix (a pun on MULTICS, an earlier project Thompson had been working on).
However, things really got started when Dennis Ritchie came up with a new
programming language for this new operating system, called 'C'.
Although Unix was less efficient than the vendor supplied operating systems,
it had three decisive advantages: it could be ported to any machine you happened
to have around, the included 'C' language made programming by several magnitudes
easier and it was free. Soon, universities all over America began equipping
their machines with Unix.
Terminals
So Unix was (and is) an operating system running on
a wide variety of machines. What about the people who used these machines?
These people connected to these machines via 'dumb' terminals,
i.e. machines consisting of a keyboard, a monitor and enough electronics
to hold a connection to the central computer. What users at these terminals
did was basically teletyping, thus the string 'tty' for terminal device files
or the name of the 'getty' command.
You may ask yourself what all this has got to do with
the topic at hand. Well, the vendors of these terminals couldn't agree on
a standard. That is, each brand of terminals had its own keyboard layout,
its own method of displaying characters on the screen, its own ideas what
signals sent and received represented what characters or control codes and
so on.
In order to cope with this chaos, a central file containing all the different
and differing terminal capabilities was created, the termcap. Open '/etc/termcap'
in a text viewer and stand amazed (or frightened ;-)).
Linux terminals mostly use either 'vt100' or 'linux'
as their terminal type.
xterms
In the early Eighties, the X Window System, a graphical
subsystem for Unix, was developed. XFree86 was forked from this system in
the early 90s in order to write a version more stable on the then fledging
Intel-based Unix clones like FreeBSD, NetBSD or Linux.
The first and foremost use of X was running multiple
'virtual' terminals on it. X even came with such an application, 'xterm'.
Therefore you'll find that 'xterm' and 'virtual terminal' are often used
synonymously. When you read 'open an xterm', you don't actually have to install
and use the 'xterm' program, any other terminal emulator, like rxvt, konsole,
aterm, eterm, wterm, etc, will do, too.
A terminal emulator (another name for 'virtual terminal')
connects to the system via a pseudo tty device file, pty, and uses its own
display standard, 'xterm'. This might lead to a slightly different behavior
of some keys or applications on different terminal emulators, depending on
how good these emulators emulate the 'xterm' display standard.
Shells
In order to run programs on a terminal, a shell is needed.
The shell is that part of an operating system which communicates with the
user and allows communication between commands.
The first 'real' Unix shell, 'sh', was written around
1975 by Steve Bourne,
and is thus also called the 'Bourne shell'. Soon others developed, some based
on the original Bourne shell like (pd)'ksh' or 'zsh', which are often used
as the standard shell on proprietary Unixes, or the shells which implemented
features from the 'C' programming language, like 'csh' or 'tcsh'.
In Linux, the standard shell is 'bash', the GNU Bourne-Again
Shell (well, Unix humor ...). It is very powerful (some would say, bloated),
the compressed (!) man page alone weighs some 50 KB.
section index top
First of all, a little note: you should not use the
shell as 'root' for everyday tasks, especially if you are just beginning
to use it. You can't damage the system accidentally (or even intentionally)
when being a user; as 'root', however, a simple typo can have unforeseen
and severe consequences.
The first thing you see after logging in or opening
an xterm window is the prompt. The standard prompt on Mandrake Linux consists
of your user name, the name of the machine you are logged into (if none is
set, 'localhost' is used), the directory where you are (the 'working directory')
and the prompt sign:
[tom@belbo tom]$
I'm logged in as user 'tom' on my machine which I've
called 'belbo' and I'm in my home directory, '/home/tom'. The prompt for
'root' looks like this:
[root@belbo root]#
You see that apart from the different name, the prompt
sign has changed from a '$' to a '#'. It is traditional on Bourne shells
to end a user's prompt with '$' and root's prompt with '#'.
Every aspect of the prompt is customizable, you will
read about that later on.
To run a command, you type the name of the command after
the prompt and then hit the <ENTER> key. The shell searches
for the command in its search path (more on that later, too), runs the command,
prints the output of the command (if any) on the terminal and presents you
with a new prompt when the command is finished:
[tom@belbo tom]$ whoami
tom
[tom@belbo tom]$
By the way, it does not matter where the cursor is when
you hit the ENTER key, the shell will always read the complete line.
Basic commands are 'ls' (list directory), 'cp' (copy),
'mv' (move / rename), 'cd' (change directory), each coming with a wealth
of options listed in their respective man page (man ls, man
mv etc).
Before you start off into shell land, a quick introduction
into terminology. Commands take options and/or arguments:
mv -i file dir
'-i' is an option to the 'mv' command, whereas 'file'
and 'dir' are arguments. Available options are explained in detail in the
command's man page (man mv in this example), whereas arguments
are supplied by you. Options modify how a command works, whereas
arguments determineon which data the command should be performed.
So far, this looks very much like the DOS shell almost
everyone hates and despises (and rightfully so). Time to introduce some mechanisms
which make your shell life a much more pleasurable experience.
section index top
 Auto-completion,
command line editing and history, shortcuts
|
