A Brief Introduction to Unix With Emphasis on the Unix Philosophy And How to Apply it to Do Your Work by Corey Satten corey@cac.washington.edu Networks and Distributed Computing, CAC University of Washington, HG-45 Seattle, Washington 98195 Overview Unlike a traditional introduction to Unix, the emphasis of this one is on philosophy and brevity. When you understand how the creators of Unix intended you to use it, you'll approach Unix on it's "best side". This introduction intends to help a new Unix user get started on the right foot quickly. For more infor- mation, readers are referred to the Unix manuals and other listed references. As little detail as possible has been duplicated from the manual. Copyright (C) 1989, University of Washington Commercial use of this document requires permission from NDC Version 1.24 - last modified July 27, 1989 1. Why Use Unix? In some ways, Unix is "old technology" - it was invented in the late 1960's for a small computer with a 64K-byte address space, it is largely character oriented (not graphic). Why is it still here? Why is it spreading to more and more systems from PC's to Cray Supercomputers? One answer is that Unix is written in a mostly machine independent way (in the high level language "C") and is therefore more easily moved to new machines. Once Unix has moved, a large base of applications also moves easily and your investment in learning Unix continues to pay off. Another answer is that many problems are still character oriented (or at least can be approached that way) and for these problems, like a sharp tool in the hands of a skilled user, Unix really helps you get your work done. Also, you can use Unix from any kind of terminal and over dial-up phone lines or computer network connections. In the space below, I hope to convey, with a minimum of specific information, the essence of "The Unix Philosophy" so that you can use and enjoy Unix at its best. To try to summarize in just two sentences (for those who really believe in such brev- ity): Unix comes with a rich set of connectable tools which, even if they don't directly address the problem at hand, can be conveniently composed (using the programmability of the command interpreter) into a solution. Unix also imposes relatively few arbitrary limits and assumptions on the user or the problem domain and has thereby proven to be a suitable platform on which to build many useful and highly portable research and commercial applications. 2. Essential Commands and Concepts Before I can realistically hope to say more about Unix in general, or give meaningful examples, I must briefly explain some Unix commands and concepts. These descriptions are intentionally minimal. You will soon see how to find more detail in the manu- als. 2.1. Login Unix is a multi-user operating system. This means that several users can share the computer simultaneously. To protect each user's data from damage by other users, Unix requires each user "login" to the system to identify him/herself (with a login name) and authenticate him/herself (with a password). During the login process, a user's defaults and "terminal type" are usually established. The mechanism Unix uses to allow concurrent users also allows each user to have more than one program (also called "process" or "commands") running concurrently. You will see shortly how convenient this is. - 1 - 2.2. The Shell, Commands and Arguments Once you have logged in, you will be running a program called your "login shell". The shell is a program which executes the commands you type in and prompts you when it is ready for input. One of the nice features of the Unix shell is that it is a powerful programming language unto itself, however one need not program it to use Unix. There are several different "shell" pro- grams in common use: csh (c-shell), sh (bourne-shell), ksh (korn-shell), vsh (visual-shell) to name a few. Most people use "csh". Unix commands consist of a program name followed by options (or arguments) to that program (if any). One or more spaces fol- low the program name and separate arguments. Each program exam- ines its argument list and modifies its behavior accordingly. By convention, arguments which begin with a dash are called "switches" or "flags" and they are used to request various non- default program behavior or to introduce other arguments. It is occasionally important to remember that it is the shell which does filename expansion (such as turning "*.old" into "a.old list.old program.old"). Programs normally don't ever see un- expanded argument lists. Many Unix programs can also take impli- cit arguments. These are available (to every program you run) via the "environment". Your "terminal type", stored in an environment variable called TERM, is an example of this. The manual for each program you use should list the environment vari- ables it examines and the manual for your shell explains environ- ment variables in detail. 2.3. On-line Manuals Before getting into any specific commands and examples, note that most Unix systems have both on-line and printed manuals. Many commands will be mentioned below in passing without explana- tion. It is assumed that the interested reader will look them up in the manual. The on-line manuals generally contain only the numbered sec- tions of the printed manuals. The tutorials and in-depth arti- cles are usually only in printed form. This introduction intends to reproduce as little of the information contained in the Unix manuals as possible. For more information on any Unix command, type "man command" ("man man", for example gets you "the man- page" for the on-line manual command: man). (Note: if you are prompted with the word "more", you are interacting with the "more" program. Three quick things to know: you may type a space to get the next screenful, the letter "q" to quit, or "?" for a help screen.) Among other things, the man-page for the "man" command points out that "man -k word" will list the summary line of all on-line man-pages in which the keyword: word is present. For example, "man -k sort", will produce something like this: - 2 - comm (1) - select or reject lines common to two sorted files look (1) - find lines in a sorted list qsort (3) - quicker sort qsort (3F) - quick sort scandir, alphasort (3)- scan a directory sort (1) - sort or merge files sortbib (1) - sort bibliographic database tsort (1) - topological sort This tells you that section 1 (user commands) of the manual has man-pages for comm, look, sort, sortbib, tsort. Use the man com- mand on any of these to learn more. The other numbered sections of the Unix manual are for system calls, subroutines, file for- mats, etc. You can find out about each section of the manual by saying, for example, "man 2 intro". Enough about manuals. 2.4. I/O re-direction: stdin, stdout, stderr, pipes By convention, whenever possible, Unix programs don't expli- citly specify from-where to read input or to-where to write out- put. Instead, programs usually read from "standard input" (stdin for short) and write to "standard output" (stdout). By default, standard input is the keyboard you logged in on and standard out- put is the associated display, however, the shell allows you to re-direct the standard output of one program either to a "file" or to the standard input of another. Standard input can be simi- larly redirected. Perhaps Unix's greatest success comes from the ability to combine programs easily (by joining their standard inputs and outputs together forming a pipeline) to solve poten- tially comple...
chomik33210