It's hard to get much accomplished without running a program; you might be able
to prop something up with your computer or hold a door open, and some will
make the most lovely humming noise when running, but that's really about it.
And I think we can all agree that its use as a humming doorstop isn't what
brought the personal computer the popularity it now enjoys.
So, remember how almost everything in Linux is a file? Well, that goes for
programs, too. Every command you run (that isn't built into the shell)
resides as a file somewhere. You run a program simply by specifying the full
path to it.
For instance, remember that su command from the last
section? Well, it's actually in the /bin
directory: /bin/su would run it nicely.
So why, then, does just typing su work? After all, you
didn't say it was in /bin. It could
just as easily have been in
/usr/local/share, right? How did
it know? The answer to that lies in the
PATH environment variable; most shells have either
PATH or something very like PATH. It basically
contains a list of directories to look in for programs you try to run. So
when you ran su, your shell ran through its list of
directories, checking each one for an executable file called
su that it could run; the first one it came to, it ran.
This happens whenever you run a program without specifying a full path to it;
if you get a Command not found error, that
only means that the program you tried to run isn't in your PATH.
(Of course, this would be true if the program doesn't exist at all...) We'll
discuss environment variables in more depth in the section called The Bourne Again Shell (bash).
Remember also that “.” is shorthand for “the directory I'm
in”, so if you happened to be in
/bin, ./su would
have worked as an explicit full path.
Nearly every shell recognizes some characters as being substitutes or
abbreviations that mean “anything goes here”. Such characters
are aptly named “wildcards”; the most common are
* and ?. By convention, ?
usually matches any single character. For instance, suppose you're in a directory with three files: ex1.txt,
ex2.txt, and ex3.txt. You want to
copy all of those files (using the cp command we cover in
the section called cp in Chapter 10) to another directory, say
/tmp. Well, typing
cp ex1.txt ex2.txt ex3.txt /tmp is entirely too much work.
It's much easier to type cp ex?.txt /tmp; the
? will match each of the characters “1”,
“2”, and “3”, and each in turn will be substituted
in.
What's that you say? That's still too much work?
You're right. It's appalling; we have labor laws to protect us from that
sort of thing. Fortunately, we also have *. As was already
mentioned, * matches “any number of characters”,
including 0. So if those three files were the only ones in the directory, we
could have simply said cp * /tmp and gotten them all in
one fell swoop. Suppose, though, that there is also a file called
example.txt and one called hejaz.txt.
We want to copy example.txt but not
hejaz.txt; cp example* /tmp will
do that for us.
cp example?.txt /tmp, would, of course, only get our
original three files; there's no character in example.txt
to match that ?, so it would be left out.
(Here comes something cool.)
Y'know what that is? That's me running ps to see
which processes are running; ps is covered in
Chapter 11 That's not the cool part. The cool part is
> blargh, which means, roughly, “take
the output from ps and write it to a file called blargh”. But wait,
it gets cooler.
That one takes the output from ps and “pipes”
it through less, so I can scroll through it at my leisure.
This is the third most commonly used redirector; it does the same thing as
“>”, except that “> >” will append output
from ps to the file blargh, if said
file exists. If not, just like “>”, it will be created.
(“>” will obliterate the current contents of
blargh.)
There is also a “<” operator, which means
“take your input from the following”, but it's not used
nearly so often.
$ fromdos < dosfile.txt > unixfile.txt |
Redirection gets really fun when you start piling it up:
That will run ps, reverse the lines of its output, and
append those to the file blargh. You can stack as many
of these up as you want; just be careful to remember that they get interpreted
from left to right.
See the bash(1) man page for more detailed information
on redirection.