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 much 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 Section 8.3.1.
Remember also that “.” is shorthand for the current directory, 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 Section 10.5.1) 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 ex.txt and one called hejaz.txt. We want to copy ex.txt but not hejaz.txt; cp ex* /tmp will do that for us.
cp ex?.txt /tmp, would, of course, only get our original three files; there's no character in ex.txt to match that ?, so it would be left out.
Another common wildcard is the bracket pair [ ]. Any characters inside the brackets will be substituted in place of the [ ] to find matches. Sound confusing? It's not too bad. Suppose for instance, we have a directory containing the following 8 files: a1, a2, a3, a4, aA, aB, aC, and aD . We want to only find the files ending in numbers; [ ] will do this for us.
% ls a[1-4] a1 a2 a3 a4 |
But what we really want is just a1, a2, and a4? In the previous example we used - to mean all values between 1 and 4. We can also separate individual entries with commas.
% ls a[1,2,4] a1 a2 a4 |
I know what you're thinking now, “Well what about letters?” Linux is case-sensitive, meaning that a and A are different characters and are only related in your mind. Capitals always come before lowercase letters, so A and B come before a and b. Continuing with our earlier example, if we wanted files a1, and A1, we can find these quickly with [ ].
% ls [A,a]1 A1 a1 |
Note, that if we had included a hyphen instead of a comma, we would have gotten incorrect results.
% ls [A-a]1 A1 B1 C1 D1 a1 |
You can also combine hyphen and comma strings.
% ls [A,a-d] A1 a1 b1 c1 d1 |
(Here comes something cool.)
% ps > blargh |
Y'know what that is? That's me running ps to see which processes are running; ps is covered in Section 11.3. 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.
% ps | less |
That one takes the output from ps and pipes it through less, so I can scroll through it at my leisure.
% ps >> blargh |
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:
% ps | tac >> blargh |
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.