authored by Alan McConnell

*************
Part 1 of 3, Brief UNIX overview
*************

This is the first posting of a three-part upload.  It is intended to be a
brief succinct cursory short lapidary summary of the very minimum that any
new Unix user _must_ know.  I would ask anyone who frequents this
Conference to let me know what I have omitted/over-emphasized/
mis-stated/f**ked-up in these three postings; all comments, even the most
destructive, are welcome<g>.

Unix has an interesting past.  Most people by now know the story of the
young Bell Labs hackers Ken Thompson, Brian Kernighan, Dennis Ritchie, and
others, frustrated because their main project had been cancelled, who
"found a cast-off DEC PDP-7" . . . and the rest is history.  Two things
united in order to make Unix the dominant force it is today: first, the
people who designed it were not only smart, but wise -- they made good
choices for the most part; second, Unix was essentially given away during
much of the seventies, so it could be hacked, amended, fooled-around-with;
it was never (except at the beginning) the exclusive property of one
company, the way VMS(DEC), MVS(IBM), DOS(MicroSoft), MacOS(Apple) are.

The complaint has often been made: Unix is not "user-friendly".  It must
be conceded that there is more than a little truth to that charge.  Unix
is a multi-user, multi-tasking operating system.  It sets itself higher
goals than do e.g. DOS or MacOS, and therefore is necessarily more
complex.  But it is not _that_ difficult.  People with enough moxie to
join CPCUG and the MIX have more than enough savvy to make themselves Unix
competent in a very short time.

And there are many rewards for those who choose to do so.  For one thing,
Unix, or systems similar to Unix, are here to stay.  The "installed base"
of DOS and Windows users is vast, but as we all know the plug is soon to
be pulled on DOS and Windows; Bill Gates is about to convert us all to
Windows NT.  And maybe OS/2 will make it, maybe it won't.  But all these
systems have taken over many of their basic ideas from Unix.  Indeed it is
not too much to say that they are all in many ways "dumbing down" from
Unix.  In the meantime, the professional computer people, the people who
deal with Crays, Convexes, SGIs, Suns, HPs, . . . the scientists, the
networking experts, the people who are designing the computer systems and,
more important, the computer _networks_ for tomorrow . .  . these people
are all using Unix in one form or another.   It is as sure as any peek
into the future can be that the interesting exciting work whose shadow can
be discerned as we peer ahead into the 21st century will be work done on a
Unix platform.

Is Unix for everybody?  That is hard to say.  Certainly Unix on an
individual home machine seems to be a bit of overkill(why multi-user? why
multi-tasking? "let the damn thing do what I tell it to when I want it
to!").  But then we come to networks, and computer communications, and
here is where Unix comes in to its own.  Despite its admitted complexity,
the betting now is that Unix is in the future of any person who desires to
become seriously involved in computer networking.

Diatribe against Menus(flame-bait):  I am against menus, for two to me
very adequate reasons.  1) menus take away your freedom.  If you use a
menu to Email, you are using the mailer the menu designer chose, not one
of your choice, configured the way you like it.  Ditto for editors, file-
finders, news-readers.  2) menus never give you enough information; for me
at least they are hard to figure out.

Here's what I use instead.  I create a file called tips.doc, and put into
it, in my own way, the information _I_ need:  where things are, warnings
about tricky syntax in seldom- used commands, whatever.  Then when I need
to know something, I go: cat ~/bin/tips.doc(I keep tips.doc in my bin
directory), and there is the information _I_ need, easily recalled to me.

I should be very pleased if information from the following two uploads
should find their way into _your_ tips.doc file!


*************
Part 2 of 3, DOS to Unix dictionary
*************

This second part of a three-part upload is devoted to a DOS-UNIX
dictionary, plus some comments on various aspects of Unix-speak.  Let me
first give two IMPORTANT TIPS:
 a) the directory separator slants thusly / and not, as in DOS, thusly \
 b) in Unix, _case matters_; MKDIR is not the same as Mkdir is not the
    same as mkdir.

        DOS                             UNIX
        mkdir                           mkdir
        rmdir                           rmdir
        dir                             ls -l(ls alone gives
                                             shorter listing)
        copy                            cp
        del                             rm
        . (the current directory)       .
        .. (the directory just above)   ..
        cd                              cd
        * (most common wild card)       *
        type                            cat
        LIST(a la Buerg)                more(or an enhanced
                                         command, humorously
                                         named: less)
        (I can't think of any more _basic_ commands, can you?)

Unix commands are executed by a so-called shell, roughly corresponding to
COMMAND.COM in DOS, except much more flexible.  For one thing, there are
different shells; the original shell, sh, was written by Steve Bourne of
Bell Labs sometime in the middle Triassic, but many more have been
developed since: csh, tcsh, ksh, bash are the most frequently
encountered.  When you log on to a Unix system, the system will start up a
"login shell" for you, a program in whose tender hands you will be for the
duration of your session.  It will interpret your commands, checking first
whether you are allowed to issue them.  The Sysop of the system you are on
can, and doubtless will at your request, change your shell.  Which shell
is to be preferred is the subject for theological one-upmanship; the later
ones, tcsh, ksh, or bash, have more capabilities and one of them is almost
certain to be your login shell.

Redirection:  the "cat" command, mentioned in the dictionary above, opens
a (text) file, and writes it to the screen.  If you want it written to a
new file, you can go e.g.:

    cat report1.doc > report2.doc

This is another method of copying a file.    For an example of "input
indirection"( < ), see the section on elm in my third upload.

Pipes: the output from one command can be "piped" into the input of
another command(the symbol for a pipe is '|').  For example, here are two
methods of determining which shell you are using. The first one; enter:
echo $SHELL; the echo command will write to the screen the _value_ of the
global variable SHELL(if you go: echo SHELL the echo command will write
the word SHELL!)  The second method uses a pipe; enter:  cat /etc/passwd |
grep alan.  You will find on the screen all lines of the (very important)
passwd file which contain "alan", and the last field in that line contains
alan's login shell.

Aliases:  aliases are supported by most modern shells, including tcsh,
bash, and I believe ksh.  If you don't like 'cp', you can enter: alias
copy 'cp', and then you can 'copy' files instead of 'cp'ing them.

There is a form of "help" in the Unix world, but I hesitate to mention it
since it manifests Unix as its "user-unfriendliest".  I speak of the
so-called "man" pages.  "man" stands for Manual.  If you need to know
something about e.g. the "grep" command, mentioned two paragraphs above,
enter: man grep.  You will be rewarded with a rather formal set of pages
that will tell you a great deal about the various options and parameters
of "grep" but perhaps will leave you feeling you've seen a great many
interesting trees and you just wish you could catch a glimpse of the
forest<g>.

A couple of words about the 'ls' command.  ls, by itself, will display a
scroll of simply the names of the files in the given directory.  I myself
have aliased "list" to 'ls -CF'; the options "CF" put the files into
Columns and specify which kind of File it is: if it is a directory the
name is followed by a '/', if an executable the name is followed by a '*'.
(BTW options to commands in Unix are usually signalled by a hyphen, as
above.)

Hidden files: they exist and stay hidden because they begin with a '.'. 
Examples are: .login, .bash, .elm, .emacs.  These files usually are
initialization files for major programs, they reside in the user's home
directory, they can be viewed and edited much as other files, and they
become visible by going: ls -a.   The ls command has about a zillion other
options; to learn about them, go: man ls.

Finally, here is a third important tip: when a file is deleted in a
multi-user, multi-tasking operating system, it is _gone_, vanished, it is
_history_.  This means that it is smart to alias 'rm' to 'rm -i', which
means that you will be queried before the file is deleted, and you must
confirm with a 'y' or 'n'.    I strongly recommend using this alias.


*************
Part 3 of 3, editors and mailers
*************

This final part of a three-part upload treats of editors, and mailers.  If
you can create a file stating your wish, complaint, or question, and can
send it off to someone(usually your system administrator), you may be
lost, but you will not be abandoned; help is on the way!


Editors
There are roughly 10^4 Unix editors, all with -- doubtless<g> -- their own
unique virtues, and all with -- certainly<g> -- their passionate
devotees.  pico, joe, jove are the names of three I have had occasion to
run into.  But there are two main contenders for Editor Supreme in the
Unix World: vi, and emacs.

emacs
Let me dispose of emacs first.  emacs is _my_ editor of choice, it is the
editor of hairy-chested he-men<g>.  It is almost infinitely malleable,
extensible, customizable.  And IMHO it ain't that difficult to get used
to.  But I shall not discuss it here for two reasons:
 a) I wish to be fair
 b) by entering simply 'emacs', and then, following the directions
    (Ctrl-h, t), you can enter an elegant tutorial that will quickly
    teach you enough about emacs to get you going.

vi
I turn to vi, which I don't particularly like.  But it does have the
advantage of being _universally_ available in the Unix world, and it has
its devotees.  I begin by stating that vi has two modes: command mode, and
entry mode.  If you are in command mode, keystrokes will move the cursor,
delete/ transfer text, etc; if you are in entry mode, keystrokes will add
text to the file you are editing.  You start out ("vi file_to_be_edited")
in command mode, and you can always return to command mode by hitting the
ESC key.  When using vi I keep tapping the ESC key, so that I don't find
the commands I am entering showing up in my text<g>.

vi commands:
 - Cursor movement is achieved by the four keys h(left), j(down),
   k(up), and l(right).
 - If you want to go to the beginning of the line, enter 0; to the
   end, enter $.
 - To go to the beginning of the file, enter 1 G, to go to the
   end, enter simply G.
 - To delete the character the cursor is over, enter x; to delete
   the whole line the cursor is on, enter dd.
 - To write(save) the file you are working on, enter :, then w;
   to quit, enter :, then q.  If you've changed a file, but don't
   want to save the file, simply want to get outta there, enter :,
   then q!.

Very good so far.  But how do you enter text?  There are four basic ways
to change from command mode to entry mode:

First:  move your cursor to where you wish to enter a character(s),
    then type 'i'; every character you type from then on will be
    entered into the file(until you hit ESC). 

Second: move your cursor to just before where you wish to start
    entering text(e.g. to end of file), and type 'a'; the cursor
    will move a place forward, and everything you type from then on
    will be entered into the file(until you hit ESC).

Third: suppose you wish to open a line below where the cursor
    is.  Simply type 'o'; your cursor will appear on the line opened
    below where your cursor was, and you can type in text.

Fourth:  suppose you wish to open a line _above_ wher the cursor
    is.  Simply type 'O'; your cursor will appear on the line opened
    above where your cursor was, and you can type away.

As always, ESC returns you to command mode.


Mailers
Of course I haven't told you all about vi, but I believe I've given you
enough to get started.  Let me tell you about mailers.  I know of four:
mail, Mail, pine, and elm.  I'm going to tell you about elm, which I
consider the best.  elm is universally available, and is wonderfully
configurable.  If you want to use one of the others, you will have to read
the "man" pages(e.g. go: man pine).

Suppose you have been alerted immediately upon logging in: You have new
mail.  Simply enter 'elm', and you will see a nice display showing you the
names of the senders and the Subject of the messages.  You can move the
cursor up and down(using the Arrow keys) to decide which message to read,
and when you hit Enter you will be able to read the highlighted message.
You can then reply to the message, using your preferred editor (your
options are set in the elmrc file, in the (hidden) directory .elm), save
it to a file, delete it, forward it . .  . elm has a nice help facility to
remind you how to do these things.

The nicest thing is how to send a message.  You can of course do it within
the elm program, but I prefer to draft letters outside the program.  When
you've got a file ready, say alan1.let, a file in which you've bawled me
out for not having warned you of some Unix pitfall, you can go: elm
alan@clark.net < alan1.let , and within minutes the message will have
arrived in my ClarkNet mailbox(note the redirection here -- I described
redirection in the second part, but here is the first example of
redirection _into_ a command).  Complaints or queries to the local sysop
can be sent to:  root@(localsystem)