|
|
Unix for Poets!
|
| by Betsy Aoki
|
Introduction
I wrote this piece at a critical moment in my Unix thinking — that is, right after I’d had a crucial AHA about how the operating system works, but I hadn’t gone so far down the road that I had the smug innate understanding of someone from the Bell Labs. (I think we have all met this sort of Unix impresario — they make cracks about Microsoft that are immensely funny, and then immediately make your eyes glaze over by knowing an obscure machine language command that only Linus Torvalds was supposed to have known.)
Now, don’t get me wrong. The Unix dudes with the big beards and glasses who struggled through all the Unix development from the 1970s until now have done an immense amount of work. They have had to create, master and remember a system that grew organically and at times rather haphazardly, and still manage to make jokes like having the command "less" equal "more" only with more features. (Less = more, only more so. Get it?)
But as a novice, especially a female one, you end up feeling like you must trust these strange gurus, sitting like a little bimbo at their feet, and you are not 100 percent sure that they are bullshitting about how hard it is. Having worked around a lot of tech people, I can say that a fair amount of intellectual one-upmanship goes on — can you solve this problem/ do you know this obscure answer/ can you really do "it" (hack, set up a firewall, whatever). You participate in many trial by fire conversations that can be quite intimidating. For the novice, or at least for me, what was needed is compassionate, humorous understanding…after all, these guys have learned Unix and they know how funny and how irritating it can be.
Take heart. There is light after the long tunnel. After study, work experience, classes or whatever it takes, you can make the transition from overwhelmed to Getting It, and find you have the mental tools you need to dig deeper and if you like, become one of those impresarios. I wanted to record this crucial transition on paper because this is the point where most books and online help failed me, and where a class made the difference (thank you, Tim Maher at Consultix! And the folks at DigitalThink!)
This document does not take the place of RTFM (read the fuckin’ manual) or getting yourself a good set of books or a class. The hope is that after reading this you can get a better sense of things that made you scratch your head, so that when you go back to the man pages or to your O’Reilly book, the sentences they use make more sense to you.
If it gets you more confused, well, at least it was free.
Back to top
Okay, but who are you, Betsy?
I’m someone who has struggled with Unix for a long time. As an English major talked out of a computer science degree at UC Berkeley in the 80s, I pinged around on the VAX machines and fingered my boyfriend from MIT (lame pun, sorry), but I did not get beyond understanding the basic Unix directory structure and playing Hack. When I got to the UW, same deal, except the World Wide Web was exploding, and I was using my knowledge of Unix directory structure to move Web pages and multimedia files around.
Then came Linux, and I realized
- I was in my early 30s, time to stop dating programmers and just learn the damn thing myself
- I didn’t have to buy a Sun workstation -- I could do it at home with a PC and RedHat
- I had just been told there was no Seattle Linuxchix chapter, I’d have to start one, and
- I’d look real dumb if I didn’t understand Unix while I was leading the chapter.
I do not have a computer science degree. I have an MFA in poetry. Take heart.
Side note: This document will refer to the generic male or female in the third person as "she." This is not a feminist rant or a desire to exclude guys, but I find that when I read something and the author has taken the time to put a "she" into the sentence, it makes me feel warm and fuzzy. Like I was uniquely welcomed into the text. Yes, I know "he" is supposed to stand for male or female in our culture, but it’s funny how that one word changes things.
And yes, I know Linux is not technically Unix. But as I’m learning Unix on Redhat Linux 6.2, I figured I’d be as honest as I can and say: on a different flavor of Linux or commercial Unix, your mileage may vary.
The moving parts of the machine
If anyone has ever taken you and shown you what’s under the hood of your car, the first thing you see is a jumble of metallic shapes and parts and wires. Little by little as they explain it to you, you get the idea of how they work together to make your car go.
A computer running the Unix operating system is going to seem like that incomprehensible metallic jumble at first. You feel like you have the hood open and can yank out or pull on anything, and possibly blow up the car before you drive it. Unix appears that way to everyone, so don’t worry — the impresarios have just forgotten this part of their education.
I won’t go into immense levels of detail about the hardware and the Unix kernel, which is the key piece of programming that makes the operating system go. For one thing, your eyes would glaze over, and another thing, I don’t know that much. But I can talk about what tricks you can use to visualize what is happening when people talk about commands and such in Unix.
When you boot up your Linux box at home, you will be prompted to log in. If you have a graphical interface like GNOME or KDE running on your machine, you’ll see some Windows-like menus and scrollbars and buttons come up after you log in as root successfully; for others, you will just get a dark screen and a command line prompt. (Graphical interfaces will also allow you to start a "terminal window" on your screen; check your documentation for details. In Red Hat 6.2 KDE there is a button on the bottom menu that kicks up a new terminal window.)
Back to top
Bring in the Command Line Commandos
Remember Neal Stephenson’s book, "In the Beginning was the Command Line?" Well, the guts of Unix is telling the computer to do stuff at the command line.
This is where the impresarios get annoying. They look at that little $ or #: and type something like
ls —l | tail +2 | grep —v ‘^[ld]’
and stuff happens, whereas you worry about even where to begin without breaking anything important.
While the command line is something to be respected, at times feared, and something to be highly annoyed at, it is also something to be grateful for. The chief moving part in the Unix operating system is YOU. That means that if something screws up, you have a chance at fixing it without getting messages like "fatal exception; computer meltdown" and then ominous silence. The ominous silence starts at the beginning, with the command line. You are always typing into the Void, but the big payoff is when the Void starts doing what you are telling it to. I know, it may seem easier to just click on something, or just drag and drop in your other desktop environments. But there’s nothing funny or challenging about that. And, it’s not really in the spirit of Unix. The Unix is really a trust-yourself, do-it-yourself culture.
The thing that makes me keep coming back to Unix, even though I was steered away from computer science as a major, is that it was created by people who had a great sense of humor even as they were torturing all of us by creating commands that pretend to be in English. The command line lets you pun to a computer, and it will do exactly what you say. The command line is like the baton of a conductor — and you get to lead the orchestra. There is also a nicety of the precision required by Unix — the computer will do what you tell it to, not more, not less (unless you are doing that more or less commands I told you about earlier).
Back to top
Consulting your inner daemons
Okay, so you can make stuff happen to a Unix box by typing at the command line. But what else is going on?
When the computer starts up, many things start happening at once. The kernel, or software guts of the Unix operating system, fires up and automatically starts some processes in preparation for something happening by the user.
This is where I have to take a deep breath and talk about files. Everyone knows what a file is in the real world — you have manila folders, you have file cabinets, you put something in a filing cabinet and it is a file.
In Unix, a file is more than that. While it exists in some senses like the manila folder you put on the boss’s desk, it also behaves like one of those cursed magic books in the stories that burst into flame, or made people keep reading them once they were opened. A file in Unix can compel the kernel or shell to keep reading it and do what it says. In English major terms, it acts like a noun AND a verb — you can have a file with data in it, a "noun" or you can have a file that when it is invoked, starts things happening.
So, when you start poking around the innards of your Unix machine, you see all these files lying around. You see them lying around in directories in Linux like
bin or /usr/bin — where user commands are stored (now remember, commands are really files. )
sbin — location of system commands, has also /usr/sbin counterpart
root — the home directory of the mighty root
mnt — this directory has the mount points for other filesystems once the original system boots, don’t pay attention to this one now
boot — contains the kernel and other startup accessories
lost+found — stores orphaned or nameless files, used by fsck
lib — library files for programs in /bin and /sbin
dev — stores files for devices like your CD player
etc — you will play in this one a lot. Has configuration files and directories, including passwords
var — this is the place for files that change a lot on the fly, like the printer spool and logs and such
usr — it’s all about the user here
proc — okay, I don’t really get this one, but has information for programs
tmp — a dangerous directory — everyone in the world can write and read files in this space. Important to Unix systems to have this to keep some programs running. But also a security risk you have to pay attention to.
home — where user home directories usually are
Daemons are files that when activated, flit around the system looking for stuff to do. I think of them as the junior high hall monitors of my youth. Their filenames often end in d, like inted and httpd. If the data comes through the right port or has the right pass, the daemons will take it where it needs to go. Or, you might think of daemons as waiters, standing ready to serve.
You don’t need to worry about the daemons unless you want to become one of the godlike system administrators. However, as you nose around your Linux system at home, it is good to know what you are looking at.
Processes — we can get into these more later, but essentially, once you start stirring the pot in Unix and commanding the command line, you are asking the kernel to allocate CPU time and energy toward your task, creating a job or process. The easiest way to stop things from happening is to kill the process (yes, there is a kill command) — the moral equivalent of CTRL-ALT-DELETE except there’s no niceties about it. I tend to think of processes in two ways — one I start, and ones the system starts without me. In the beginning, the main ones to worry about are the ones that you start.
When you log in as a user, you fire up an instance of the ‘shell.’ The shell is a great metaphor — I think of me the user sitting in a plastic bubble, with all sorts of dials and controls around me, hovering like a spacecraft while moving through the operating system environment. The shell is a program intended to make interacting with Unix user-friendly by creating an English language interface with the kernel. By now, you are falling out of your seat or getting the gun ready to shoot me. "English language! Betsy, are you insane?!! Nothing in this book about Unix looks like English!"
(I know, bear with me. They were programmers, they had other things to worry about, like saving keystrokes. People with carpal tunnel, rejoice, because Unix is the environment for you — you won’t type nearly as much as you might have had to.)
Okay, so you are in your shell bubble and raring to go. When you type into the command line and hit return, the shell swings into action. It breaks what you type into blocks of meaning that it understands called commands and arguments. An argument (or sometimes, an option) is essentially a word or bunch of characters that tells the shell how to execute the commands.
To execute you commands, at some point the shell has to talk to the kernel. The user (that’s you) does not talk to the kernel directly. The kernel is the only thing that can talk at a machine level with the computer.
Back to top
Getting in and getting out
As you’ve come to expect with your Windows or Mac desktop, you need to boot up the computer to get things moving. Your PC at work may require you to sign in (password protected) in order to get on your local network; your Mac at home may require no sign in. Computers with Unix on them, or "Unix boxes" always require you to log in. That is because the operating system always needs to know who you are in order to determine what you can and cannot do on the system.
Back to top
The root of the problem
Running Linux on a home machine, you get to be root. Think, "root of all evil" or "root of all good" - this is the login and password that lets you do ANYTHING. Other people only get to be users, with privileges set by root. You are the goddess, they are the sycophants.
Root password is set by you when you install the operating system. Keep that sticky note with the password on it in the safest place you can find. Some people suggest making up a password by thinking of a sentence, and using the first letter of each word in the sentence.
What is root? This is something that is a mark of distinction among hackers and tech people in various companies, system administrators, and the topic of ThinkGeek t-shirts. What does it really mean? You have the power to screw up your entire system, with only yourself to blame.
The big glitch for learning Unix is that you are starting from little knowledge and given tremendous power, sort of like Neo in the Matrix ("you are the Chosen One") and as a result, you make goofy Keanu Reeves faces. If you have a healthy self-esteem about yourself and technology, you do better in this scenario. But, even if you don’t have self-esteem (remember, I have a poetry degree) you can fake it until you have it. Just be careful about what you do and how you do it. Make backups. Buy a lot of books and read them and keep a bookshelf right by your desk with these references. Have a fast Internet connection to look things up and ask user groups some questions.
Okay, so you are now root on your home Linux system. The first advice I have for you is: get the hell out of there unless you really need to be root right now. For what we are going to cover in this document, you don’t really need to be root for most of it.
Back to top
How do I get out of root and into my regular clothes as a user?
If you already have a user account set up, you type "su" in the command line along with your other login name to get into your normal user clothes. If you have just installed and are starting from root, there are a couple things you can do.
RedHat 6.2, which I have, has a command called useradd. You type in
useradd cathy
..and suddenly you are logged in as cathy rather than as root. Root can always "be" someone else, so you don’t have to fret about passwords in this situation. If you were creating this account for a real user, you could do some commands to change the password, tell them what it is, and then have them change the password to their own liking. For now, we are just getting you into a persona.
Other systems use the command adduser. Which leads me to my next point, about the "online manual."
Back to top
All we ever needed was a good man
I don’t know about you, but all I’ve ever needed was a good man - manual page that is. Frankly, using man can scare you the first time you use it.
Because the creators of Unix understood they had created a monster, they added into the operating system an online manual that you can use to look up the meanings of commands and their usage. The problem is, the manual is also a bit of a monster — it seemingly expects you to know something about the system just to be able to use it. If you were hoping for something as consumer-friendly as the help files for any Microsoft or Apple product, you are going to be sadly disappointed.
For example, if you typed
#: man man
asking for the manual page for the "man" command, you get something like this excerpt…
man - an interface to the on-line reference manuals
SYNOPSIS
man [-c|-w|-tZT device] [-adhu7V] [-m system[,...]] [-L
locale] [-p string] [-M path] [-P pager] [-r prompt] [-S
list] [-e extension] [[section] page ...] ...
man -l [-7] [-tZT device] [-p string] [-P pager] [-r
prompt] file ...
man -k [-M path] keyword ...
man -f [-M path] page ...
Description
man is the system's manual pager. Each page argument given to man is normally the name of a program, utility or function. The manual page associated with each of these arguments is then found and displayed. A section, if provided, will direct man to look only in that section of the manual.
Another aggravating thing is, once you get into the manual mode, you have to know how to use it and get out of it…and there isn’t any prompt or clue to tell you how to use man.
Surviving your first man:
1. First, to GET OUT of man, you type a question mark.
2. To page down to what you want, hit the space bar.
The most basic way to use the man command is typing the word "man" and then the name of the command. Obviously, using man this way is rather limited — it requires that you know the name of the command first, something that no novice user can be expected to do.
More useful is adding the argument, -k , which forces the man command to look for what you want by keyword.
# man -k copy
Want to browse it through your Web browser. Check out these online manual pages:
http://www2.linuxjournal.com/help/man.html
Back to top
Dancing through the directories
Some people have said to me that Unix directories are the hardest thing to conceive of, as there is no user interface in the command line to help you visualize where you are. Desktoplike interfaces to Linux like KDE and GNOME apply a Windows-like folder structure to the Unix directories, but since you can’t do everything in the interface you can do on the command line, you are better off understanding what you are doing at the command line level than trusting the GUI. Future versions of Linux or commercial Unix may get more graphically responsible (perhaps the Mac OSX is one step in this direction) but so far, Unix and Linux are not really desktop-friendly the way these other operating systems have been.
What everyone tells you to do is think of an inverted tree structure. The root sits at the top (where the mighty root user actually is) and the branches as they flow downward into twigs bifurcate until they dead end in files, or leaves,.
This is not really accurate. Unix directories are more like gothic or science fiction stories based on the London underground. The ghostly trains move you one direction at a time, down the directory path (/usr/home/betsy) and occasionally, through the use of symbolic links or absolute pathnames, you are transported to another directory, voila! (transporter beam).
Moving around people most often use the command "cd" or change directory.
# cd here
(where here is the directory directly under my current location)
Remember, directories are separated from the things above and below them by slashes.
And the slashes go the exact opposite of the way they go in Windows.
My little ASCII diagram of the directory structure looks like this:
| |
| |
|
/usr |
|
|
| |
|
/home |
|
|
| |
|
"/betsy" |
|
|
| |
/ |
\ |
|
| |
"/betsy/here" |
"/betsy/away" |
|
| |
| |
See, /usr is "above" /home, which is where the user directories are often stored. Then comes my own user directory,labelled Betsy. Then my two little pet directories, "here" and "away."
(Here and away are not official Unix directories, I just made them up.)
The way people test that they actually got to the right directory is typing "ls" (the list command, tells you what’s in the directory you are in) or pwd, which gives you the path,.
Like riding in the ghostly tram, you can’t really see the contents of other directories unless you move step by step back up or back down the subway line. To move yourself to another directory that is not directly "up" or "down" from you, you need to use an absolute pathname.
Absolute pathnames will be familiar to most of you in dealing with the World Wide Web, either as a surfer or as an HTML coder. For example, http://www.seattlelinuxchix.com/tutorials/flavors.html is an absolute URL, starting from the top of the area open to the Web server and working down one level to where the index or home page sits. People who have coded Web pages know that you can also use relative URLS to get what you want…that is, write the link so that instead of telling the browser the entire long chain.
So absolute would be
<a href="http://www.seattlelinuxchix.com/tutorials/flavors.html">Flavors of Unix</a>
but if I were creating a Web page in the awk directory, found
under tutorials, I could write my html like this also, using a relative path:
<A href="../flavors.html">Flavors of Unix </a>
Back to top
|
|
|
