A SMALL TOUR OF UNIX

PART 2

BY DAVID SMALL START CONTRIBUTING EDITOR

Last issue, in anticipation of the UNIX-capable TT's release, we asked Dave Small to start our readers off on a tour of UNIX. Dave's first installment covered the basics of file structure and several important UNIX concepts. In this issue, Dave starts out with a discussion of the "root" and UNIX's oddly named commands and then takes you on a walkabout of a typical UNIX system.

All UNIX systems include an "ultimate user" called root. Now UNIX gurus will wince as I say this, since I'm glossing over minor points of precision but essentially this user, root, can go anywhere and do anything. Root can ignore such trivialities as permissions and can read anyone's private mail if root so chooses.

Of course, on big UNIX systems, root is used by the system gurus, who use the sign-on to keep the system running and bail the system out of crashes, when permissions and such would just get in the way. And you can bet the password to root is a closely guarded secret.

On your own individual TT/UNIX system, you may very well choose to log in as "root" all the time and dispense with all the permissions/protection folderdol I discussed last issue. This would be particularly appropriate if you're really the only user. However, root can do some fairly nasty stuff to the system that other users cannot, if you're not careful; it's probably safer to reserve using root for the (hopefully rare) times you need super-privileges and use a "mere mortal" user number for everything else. That way, if you try to do something that's certain death for the system, UNIX will protect you from yourself.

GEM? No, Command lines

On the ST, it's easy to take a "walkabout" inside the disk system and look inside of folders. To open a folder, just point at it with the mouse and double-click; you can then see its directory on the screen.

The TT is said to have something like this graphical-interface capability, but no one, including me, has seen it as of presstime, so let's continue on with command lines. I guarantee that you'll spend a lot of time in command lines in UNIX.

Command lines? If you don't know what they are, you'll probably recognize them in a moment.

On the ST, there are many command-line programs. These let you see directories by typing DIR, let you change directories by typing CD and so forth. Many command-line programs are very much like IBM MS-DOS, so that you can have AUTOEXEC.BAT batch files (groups of commands executed on startup), DEL for delete, COPY for copy, RENAME for rename and so forth. Sound familiar?

Since UNIX systems grew up before graphics were available in a standard terminal (back when the teletype-33 was the standard), they are very command-line oriented. Graphics have only recently been tacked onto UNIX and aren't well integrated into the system yet. Hence, resign yourself to staring at an 80-by-24 screen and typing lots of commands.

YACCety Yak: Those Awful Command Names

Are you a poor typist? Well, UNIX "helps" you by shortening command names. For instance, instead of DEL to DELETE a file, you use rm to REMOVE a file. MOVE (RENAME) becomes mv. COPY becomes cp. You can, with some effort, teach the shell (what you talk to) to understand commands like COPY or DEL or DIR, but it's not easy.

On the one hand, the short commands are nice for the two-finger typists. On the other hand, the replacements for the long commands are often hard to remember.

Part of UNIX's reputation for being user-hostile comes from these command names. It went from, "Well, it saves a couple of keypresses," (COPY to cp) to pure silliness: grep (GREP?!?) for "Search through files for a particular data item," YACC(for--no kidding!--Yet-Another-Compiler-Compiler) for complex language generation, and, of course, BISON for a clone of YACC (right, as in Yak, the animal). I'm not kidding, BISON is real.

Now you know why people often regard UNIX with quiet amusement when they consider new users. New users have a bad enough time just double-clicking on an icon. How are you going to teach them to run a program or do something when commands are named stuff like yag or grack or murp?

Shells and Scripts

Well, okay, let's log into the UNIX system. First, you'll get a prompt (#), telling you that you're talking to a shell, a semi-intelligent program that will "help" UNIX understand your commands.

For example, if you type "cp * / dave" (which copies all files to a subdirectory named dave), the shell does a directory of all of your files, and generates something like "cp file1 & file2 & file3 & ... & last file to / dave" to the underlying system.

Shells may also have "scripts," which UNIX calls Batch Files, written for them. These can be incredibly complex and do darn near anything; many people program UNIX just with the shell, avoiding the "C" language like the black death. (In my humble opinion, this is deserved, but I am given to understand that not everyone shares this view.) Anyway, I can do little more than touch on shell scripts, but they are there and can automate most common tasks, such as getting a beginner into a program safely. You do have to be a reasonably adept guru to write a shell script.

There are three different shells in common use in UNIX-land. There's the Bourne shell, which is default. C-language hackers tend to like the C shell. AT&T loyalists like the Korn shell. I don't know which Atari will supply; all three have fierce loyalists. It'll probably depend on which shell Atari's hackers like. My guess is that they'll supply Bourne with the C shell optional.

A UNIX Walkabout

Okay, so I'm logged in and in my shell. Let's find out what files I have in my home directory, /usr/dsmall. Instead of DIR, as you're probably thinking, I type ls. (I know, I know--ls?). What UNIX gives me is a thumbnail description--just the names--of all of the files and subdirectories/folders I have, with no length, type-of-file (program? data file? love letter?) or even if it's a subdirectory. See Figure 1.

There are good reasons that UNIX gives you so little information. Here's one: The ls command was designed for those poor old teletype-33's, which typed at a whopping 10 characters per second. (Your ST probably does 1,000 a second). Thus, when remote users wanted to see their files, they got by with the absolute minimum of information back, because it took so long for the system to type it out! (ls also has another design purpose, but we'll leave that for the future when we cover pipes and redirection.)

To get a saner view of your files, try ls -al. This gives you a complete description of the files, including permissions, owner, "group" (don't worry about it), length, type and even shows you hidden files. start is a subdirectory. To get into it and look at the files there, type #cd start [change directory to start; very much like the ST.], then #1s -al. Now, we'll return to our "home" directory, /usr/ dsmall:

#cd [remember, cd by itself takes you home.]

Let's be snoopy and go check out User Heidi's files. As we set up our theoretical system last issue, "heidi" and "dsmall" are both subdirectory/ folders of "usr". So we need to back up and change to the usr directory, then change to "heidi" and look over her files--the ones she's let me look at, anyway. This is called moving around the directory tree; it is exactly like closing a folder named DSMALL and opening the HEIDI folder on the ST.

#cd .. [This changes me to /usr, same as closing the dsmall folder.]

#1S dsmall

dwheeler heidi [These are the subdirectories.]

#cd heidi [Get into Heidi's folder area.]

#1s

mark.harmon bruce.willis clipboard.txt

Thus, we have three files. We could find out more about them by typing #1s-al, but, alas, we can't read them, since Heidi has wisely turned off anyone's but her own ability to do so.

Back to my directory. This time, let's go straight there, instead of going down to /usr then back up to usr/dsmall:

#cd /usr/dsmall

Figure 1: Is

To TYPE a file out--just list it to the screen--type--#cat letter

cat? That's short for "concatenate," I think, or perhaps the UNIX programmer that thought it up liked cats. I don't know. And don't fool yourself--some of the UNIX command names were thought up first, then have had clever rationalizations added to them as to what they stand for. One Berkeley programmer named his new command for his girlfriend ...

Anyway, what cat does is take the input you specify, and copy it to standard output. This standard output stuff is mighty cool, as you'll see next issue, but for now, it's just your terminal.

Contributing Editor Dave Small is one of a small circle of ST gurus who have helped to make the ST as popular as it is. Dane has been a pioneer in developing Macintosh emulation on the ST, culminating with the release of his latest triumph, Spectre GCR.