The Unix shell is the
program that interprets the things you type at the command-line prompt. It
is called the shell because it forms a shell
around the computer’s lower-level functions so that you, the
user, don’t have to deal with them directly.
If you’ve been using personal computers long enough to remember poking around in the DOS command-line environment, guess what? That experience is going to prove useful. In many ways working in DOS is similar to working in a Unix shell session (though Unix fans will say it’s similar in the same sense that driving a soapbox racer is similar to driving a Ferrari).
If your computing experience has been limited to using a graphical environment like Windows or the Mac OS, this is going to seem a bit strange at first. If you stick with it, though, you’ll come to appreciate the power and flexibility of the command-line interface.
It’s a bit like LEGO blocks. The command-line interface is like the LEGOs I grew up with 30 years ago: you got the little square one and the slightly bigger rectangle and the really big rectangle and so on. The individual components were basic, but if you put them together with sufficient imagination you could make a spaceship, or a fire engine, or a skyscraper, or whatever you wanted. Unix commands are designed to be put together with each other in the same way, and before you know it you’ve got a custom tool to solve whatever your particular problem is.
A graphical interface is more like those fancy LEGO sets you can buy today: premolded plastic pieces that go together in just one way. You get a much snazzier-looking spaceship, but that’s all you get. If you want a fire engine you have to buy another kit—and if you want something unusual you’re out of luck. As Net user and Unix convert Peter J. Schoenster has written, “With a PC [meaning a Windows PC], I always felt limited by the software available. On Unix, I am limited only by my knowledge.”
The hardest thing about working in command-line mode is that, well, you have to learn a lot of commands. You can’t rely on being able to click through menus to discover the one you need, or having a dialog box pop up to request more specifics when you need to invoke a command with a particular set of options. It’s very much the “open sesame” school of computing: you must know the magic words in order to get anywhere. Without them, your shell prompt will just stare at you, mocking you for your lack of clue.
It’s really not that bad, though; with a little practice
you’ll soon by tapping away like a pro (or at least like a
rapidly progressing amateur). Also, the folks who pioneered the Unix
wilderness realized that no one wants to carry around a bunch of
printed documentation, so they put a very complete set of
documentation for all these commands right there in the computer, in
the form of manpages.
We’ll
talk about them in the next section. Accessing the manpages for a
particular command is as easy as entering man
command_name at the shell prompt, which is
great—except that you still have to know the name of the
command in order to call up its manpage.
Like I said, you must learn the magic words. But only a few at a time, and if you jot them down on a piece of paper and keep them by the computer you’ll be up to speed in no time.
Unix manpages take some getting used to. Often written by the author of the program being documented, they tend to assume a fairly high level of familiarity with Unix and programming concepts. They also tend to vary quite a bit in terms of style and content. As you read more of them, though, they begin to make sense.
When you enter the command man
command_name, with
command_name being replaced by the name of
a Unix command you want to learn more about, you should get a
printout on your screen explaining everything you wanted to know (and
a good deal more, probably) about the command in question. Normally
this output will be automatically displayed for you a screenful at a
time using something called a
pager
program. One popular pager program is
called more;
perhaps inevitably, there is an updated
version of it called less. Both of them work
pretty much the same. When your screen fills up with output a special
prompt appears at the bottom of it, and when you’re ready to go
on you press the Enter key to advance a single line, or the spacebar
to advance a whole screenful. Depending on the vintage of your pager
software, you may be able to type b to go back up
a screen, and a forward slash (/) to enter a
case-sensitive search term, after which the pager will scroll forward
to the first appearance of that term. Enter q to
exit from the pager and return to your shell prompt.
So, what is it that you’ll be paging through? Making Sense of Manpages gives an overview of the contents of a typical manpage.
A few other interesting facts about manpages:
You will often see commands, or their manpages, referred to with a parenthetical number after the command name. For example, "less is a program similar to more (1). . .” What’s going on with that parenthetical number?
What’s going on is that manpages are grouped into numbered sections. Section 1 contains manpages describing user commands, so most of the time when you read a manpage you will be reading a “section 1” manpage. When a command is referred to as command (1), that means you can read about the command in its section 1 manpage. Another commonly used section is section 5, which gives file formats for various configuration and administration files.
To explicitly read a manpage from a particular section, you give the
section number as an argument to the man command,
before the name of the command itself. For example, entering the
command man 1 crontab will let you read the
section 1 manpage for the crontab command, which
lets you automatically run commands at timed intervals. Entering
man 5 crontab will let you read the section 5
crontab manpage, which describes the format of
the file you use to control these timed commands.
In practice, you don’t have to worry about supplying the
section number because the man program will search
through all the sections until it finds a manpage for the command
whose name you entered. The only time you need to worry about it is
when there are entries in different sections with the same name, as
there are with crontab.
Two more options you may sometimes want to use with
man are the
-a
option,
which causes all the manpages for a particular command to be
displayed, and the -k
option, which searches all the one-line
command descriptions for a keyword you supply. The
-k option is the same thing you get with the
separate, standalone command
apropos
. You can sometimes
use this to find the name of a command when you don’t actually
know it. For example, if you know that there is a command that
displays a calendar, but can’t remember what it is, try using
man -k to search for the
word
calendar:
[jbc@andros jbc]$ man -k calendar
cal (1) - displays a calendarLet’s
get started with our
first Unix command: pwd. Type it at your shell
prompt, and press the Enter key:
[jbc@andros jbc]$ pwd
/u1/j/jbc
[jbc@andros jbc]$
pwd stands for “print working
directory.” Entering that command at the shell prompt causes
the Unix server to print out the full path of the directory you are
currently “in.” After that it prints out your prompt
again, letting you know that it’s ready for you to enter your
next command.
If that comment about a working directory made sense to you, congratulations! This is the part where you get to rest on your DOS-era laurels while the Johnny-come-latelies do some catching up.
You must understand a simple but extremely important concept in order
to work effectively with computers: the concept of a
directory structure
. GUIs sometimes obscure this
underlying reality with user-friendly metaphors like desktops and
icons and trashcans, but to work comfortably in the world of the
command-line interface you’re going to need to come to grips
with this.
Computers store information in files. A large hard drive can have many thousands of files. To make it easier to name and keep track of them, they are organized into a system of directories, with related files kept together in the same directory and the directories themselves arranged into a hierarchical structure.
At the top (or bottom, depending on how you like to picture things)
is the root directory
. This is the directory that contains
all of the other directories and files.
Within that root directory can be various files, as well as other directories. Within those directories can be more files, and more directories, and so on, for as many levels as you need. When all is said and done, you have a hierarchy of branching directories similar to the branches of a tree, with the files in those directories corresponding to the leaves of the tree. Except that in this case, the root directory would probably correspond most closely to the tree’s trunk, which both sounds odd and conjures up a weird image of a tree that potentially has a bunch of leaves (files) growing out of its trunk and major branches.
Oh, well. Metaphors can take you only so far. If you like, you can substitute the other popular metaphor for a directory structure (the metaphor that GUIs use): a filing cabinet, with the file folders corresponding to directories and the individual documents inside them corresponding to individual computer files. To each his own. The important thing is to keep track of where you are (in other words, what directory you are currently working in, and what directories your files are in).
In the previous example, where we typed in pwd,
and the computer responded with /u1/j/jbc, the
directory we were currently in was a directory called
jbc, which was contained within a directory called
j, which was contained within a directory called
u1, which was contained within the root directory.
This form of writing the name and “parentage” of a
directory is called a
path
, and as you can see, the forward
slash character (/) is used to divide the
directory names within the path. When it is at the very beginning of
a path the slash character has a special meaning: there (and only
there) it refers to the root directory.
This particular directory (/u1/j/jbc) happens to
be my home directory on the machine http://andros.lies.com. This means it is the
directory I start off in when I first log into a shell session on
that machine. Depending on how the administrator of your server has
set things up, your home directory will be called something else,
possibly
/home/
username, with
username being replaced by your actual
username.
Designating a Path and Filename explains the various ways you can describe a file’s location within the computer’s directory structure.
So,
with the pwd
command you can see what your current working directory is. What
about looking at the contents of that directory?
For this you use the ls command. By entering it at
the shell prompt, you can get a list of the files and directories
contained in the current directory:
[jbc@andros jbc]$ ls
[jbc@andros jbc]$Hmm. In this case, we didn’t get anything (except another shell
prompt). That doesn’t necessarily mean there’s nothing in
the directory, however. In Unix systems, files can be hidden by
naming them with an initial period character (usually pronounced
“dot”). The basic version of ls
doesn’t display these files. But by supplying a
switch
to the command, you can cause it to
display them. In this case, the switch is -a,
which stands for “all,” such that entering ls -a can be read as “list files (all)”.
[jbc@andros jbc]$ ls -a
. .Xdefaults .bashrc .screenrc
.. .bash_logout .profile
[jbc@andros jbc]$So, there are some things in that directory, but all of them happen to have names that begin with a dot. It turns out this is a common method in Unix to name configuration files and other administrative stuff in a way that keeps them out of sight most of the time. Most of these files are used simply to configure your environment, which is why they’re kept hidden—so they don’t clutter directory listings.
Actually, though, they’re not all files. Two of them happen to
be directories. In Unix, directories are treated just like another
file in ls listings. With the ls -a listing, you can’t tell (unless you happen to know
already) which of those listed items are actually directories. To
find out, you need to use another switch: -l (a
lowercase letter “L”). You can shove both the
-a and -l switches together
with a single hyphen character in front of them, yielding the
following form of the ls command: ls -al. Let’s try it:
[jbc@andros jbc]$ ls -al
total 14
drwxr-xr-x 2 jbc jbc 1024 Feb 10 23:25 .
drwxr-xr-x 9 root wheel 1024 Feb 10 22:04 ..
-rw-r--r-- 1 jbc jbc 3785 Aug 22 1996 .Xdefaults
-rw-r--r-- 1 jbc jbc 24 Jul 13 1994 .bash_logout
-rw-r--r-- 1 jbc jbc 124 Aug 23 1995 .bashrc
-rw-r--r-- 1 jbc jbc 220 Aug 23 1995 .profile
-rw-r--r-- 1 jbc jbc 3166 Mar 25 1997 .screenrcThere’s a lot of information there, but most of it you can
safely ignore for now. Each line of the ls -al
command’s output describes a different file; the file’s
name is given in the far righthand column. The very first character
in each line is what tells you whether the file is a directory: a
d means the file is, in fact, a directory, while a
hyphen (-) means it is a regular file.
From the ls -al listing, therefore, you can see
that two files are contained in this directory that are not regular
files, but are actually directories: one called .
(a single period character, pronounced “dot”) and the
other called .. (“dot dot”). These, it
turns out, are special. They show up in every ls -al listing you ever do. The . directory
is just a shorthand way of referring to the current
directory
(that is, the directory whose
contents you’re looking at, the one whose name is printed out
when you enter the pwd command). The
.. directory is a shorthand way of referring to
the current directory’s parent
directory;
that is, the directory that the
current directory branches off from (or is contained within,
depending on whether you picture your directory hierarchy as a tree
or a bunch of nested file folders).
It may seem odd to you at this point to list the directory itself and
the directory’s parent in the ls -al
listing, but it actually turns out to be fairly handy at
times.
Here’s
a
command that is pretty straightforward: mkdir,
which you use to create a directory. You invoke it with the name of
the directory you want to create, and the command creates the
directory for you, as a
subdirectory
of (that is, as a directory that
branches off from, or is contained within) the current directory.
Why might you want to create a directory? In general, you would do this to create a new storage location to help you keep your various files organized. Just like in the real world, it’s a lot easier to keep track of things on a computer if you take the time to develop a system for what goes where, and then make a point of putting things where they belong.
Let’s try creating a directory called
walnuts (for no particular reason; you can call
yours foo or rutabagas or
whatever strikes your fancy):
[jbc@andros jbc]$ mkdir walnuts
[jbc@andros jbc]$Well, that wasn’t very exciting. But this is typical of Unix, which assumes that you know what you’re doing and don’t need feedback unless you specifically ask for it, or unless something goes wrong.
Entering our old friend ls -al, we get the
following:
[jbc@andros jbc]$ ls -al
total 14
drwxr-xr-x 2 jbc jbc 1024 Feb 10 23:25 .
drwxr-xr-x 9 root wheel 1024 Feb 10 22:04 ..
-rw-r--r-- 1 jbc jbc 3785 Aug 22 1996 .Xdefaults
-rw-r--r-- 1 jbc jbc 24 Jul 13 1994 .bash_logout
-rw-r--r-- 1 jbc jbc 124 Aug 23 1995 .bashrc
-rw-r--r-- 1 jbc jbc 220 Aug 23 1995 .profile
-rw-r--r-- 1 jbc jbc 3166 Mar 25 1997 .screenrc
drwxr-xr-x 2 jbc jbc 1024 Mar 13 10:35 walnutsAnd there it is, in the last line: our new directory,
walnuts.
Here’s
another
easy one: the cd command, which, if invoked with
the name of another directory as its argument, switches you to that
directory so that it becomes your new working directory. Let’s
switch to the walnuts directory we just created:
[jbc@andros jbc]$ cd walnuts
[jbc@andros walnuts]$Because my prompt is configured to show the name of the current
working directory inside those square brackets, I can see right away
that I’ve switched to that directory. If your prompt
doesn’t show your working directory, you can verify that
you’ve moved by using the pwd command:
[jbc@andros walnuts]$ pwd
/u1/j/jbc/walnuts
[jbc@andros walnuts]$A couple of useful shortcuts with the cd command:
entering cd by itself will return you to your
home directory
(the
directory you start off in when you first log in). Also, entering
cd with an argument of - (a
hyphen all by itself) will (in some shells, bash being one of them)
return you to the directory you were last in. This can prove handy
for popping back and forth between one directory and another.
Sometimes
when you enter a command at the shell
prompt your cursor will jump to the next line, indicating that the
command has been entered, but nothing more will appear on your
screen. You will see neither the output that you might have been
expecting nor the new shell prompt that tells you the command has
completed. You’ve got what’s known as a hung
terminal.
This may have happened for several reasons:
Your Internet connection may have become bogged down somewhere between you and the server.
You may have entered a command that will take a really long time to complete.
The server may be running slowly because of some other command or commands currently running on it.
You entered a command that expects some sort of extra input, and the server is waiting for you to supply it.
A quick solution to most of these problems is to hold down the Ctrl key on your keyboard and simultaneously tap the C key. This key combination (which you will frequently see abbreviated as Ctrl-C or ^C), will cancel the current command. Unless there’s some sort of problem with your Internet connection, this should return you to the shell prompt.
So,
you now know how to log into a shell
session, list the contents of a directory, create a new directory,
change directories, and cancel a command in progress to fix a hung
terminal. You also know how to use man to find out
more about shell commands, and how to use a
pager to help you read a long manpage. Those are
probably enough magic words for your first introduction to the Unix
shell. Except that you’ll need one more: the
exit command. Entering this at the prompt will end
your shell session, logging you out from the remote
server:
[jbc@andros jbc]$ exit
logoutGet Perl for Web Site Management now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
