See, it's like this: in the olden days, you communicated with a computer by flipping switches and plugging and unplugging patch cables, and there was no such thing as a "hard drive." Later came the era of paper: input on punched cards and paper tape, output on teletypes or line printers. Slow and cumbersome, yes, but somehow reassuring in a tactile way. (Also great sound effects.) Still later came interactive time-sharing systems and the era of the "computer terminal", where you communicated with the computer by typing "commands" into the terminal and the computer responded by displaying characters on the screen. This was the era that spawned Unix.
Unix and other comparable operating systems of the era (e.g., VMS and especially DOS) gained a reputation for being user-unfriendly. (I am not distinguishing here between the operating system and the user interface; it's really the latter that is the issue.) The unfriendliness stemmed in part from the fact that the user had to know a fairly large vocabulary of commands to get the system to do anything. To make matters worse, these commands were often shorthand abbreviations that were not very intuitive. And to make them still worse, users had to have a fairly deep understanding of how the computer and the operating system worked in order to use them effectively.
The graphical user interface (GUI) that most people use today, making extensive use of mouse clicks, pull-down menus, and graphical icons, owes its origins to the 1960s-era pioneers at IBM, and to Steve Jobs and the team that developed the Macintosh in the early 80's. (Microsoft subsequently produced the Windows interface, which was sufficiently different that they were able to win the copyright infringement suit that Apple brought against them. But that's another story.) The purpose of the GUI was to free people from the need to understand the "philosophy" of the operating system. While this has made computing accessible to far more people, it has the disadvantage of obscuring what the computer actually does.
Unix, in its various proprietary and nonproprietary flavors (including
Solaris, Linux and Mac OS X), is widely used in academia and elsewhere. To the
experienced user, Unix is powerful, flexible, and unencumbered by pointless
glitziness. My intent here is to help computer users who have "earned their
wings" under Windows or earlier versions of MacOS understand enough of the
Unix philosophy of that they can make the jump without too much pain. Links are
provided below to some detailed beginners' guides that deal with the
nuts and bolts.
In Unix, it is basically the user's job to know what his or her files contain, what to do with them, and how. In Windows and MacOS, the operating system keeps track of a lot of this for you. When you double-click on a file icon on your PC, the OS has to: (1) recognize that you want to access that particular file; (2) figure out what application you want to use to manipulate the file; (3) find the executable code for that application; (4) run the code; and (5) make sure that the application takes the file as input. Unix -- that is, pure Unix, without a GUI layered on top of it -- won't do these steps for you; you have to be consciously aware of what you want to have happen.
So suppose, for example, you've got an image file called 'penguins.jpg'. On your PC you'd double-click on the name or the icon, and the system would know to start up, say, Photoshop and display the file. If you try that on a Unix system you get nowhere because, first of all, Unix doesn't care about mouse clicks. Instead, you have a prompt waiting for you to type something; mabye it looks like:
So you do the natural thing and type the name of the file to open it, and this happens:
% penguins.jpg penguins.jpg: Permission denied.
Typing the name of a file does something only if the file contains executable code (and if the OS knows that it contains executable code). In fact, this is precisely the way to run a program (in PC language you'd say "open an application") in Unix: you type the name of the file containing the executable code and hit the Return key. Not only that, every command in Unix is the name of a file containing executable code. Typing the name of the file you want to look at doesn't work because the file isn't executable code; you don't have "execute permission" on the file. Instead you need to do something like:
% xv penguins.jpg
This tells the operating system to run the program 'xv'. This program is
written in such a way that it knows that if there's a file name on
the command line, it should open that file and display it.
There are many, many basic Unix commands and utility programs. They are stored in places where the operating system knows to look, so it can find them when you type their names. All of your communication with the operating system takes the form of a typed command on a line, ended by hitting the Return key. (And nothing is going to happen until you do hit the Return key!)
Every Unix command is written is such a way that it will read other stuff typed on the same command line as arguments, that is, additional information that tells it in detail what to do or what files to operate on. The number of arguments can range from none to a whole bunch; these are all the things that you would normally do on your PC under "File" or "Option" pull-downs. For example:
which lists the files in the present working directory; or
% grep penguin flightlessbirds.txt
which searches for all the lines in the file 'flightlessbirds.txt' that contain the word "penguin"; or
% tar -cvf /dev/rmt/0 /mnt/animals/aquatic/avians
which makes a tape archive of all the files in the directory
'/mnt/animals/aquatic/avians' on the tape drive device /dev/rmt/0, and
displays a "verbose" record of the process on the screen.
"Directories" are things that PC users know as "folders." Directories can contain files and/or other directories (folders within folders), and the same good work habits that make you arrange your files into folders in intelligent ways apply to structuring your "directory tree." There is a slight difference in philosophy, however. On a PC or Mac, a folder is something that you "open"; doing so gives you a window that allows you to "look into" the folder. In Unix a directory is a place that you work in, where you have ready access to the files that are stored there. At any given moment you are "in" a particular directory. This is called the "working directory"; if you forget where you are, you can use the command 'pwd' to print the working directory name on your screen.
When you are working in a particular directory you can refer to files in that directory by name. The example above,
% xv penguins.jpg
will work if you are in the directory that contains the file
'penguins.jpg' (and if the xv program is installed on your system!). If
you are not in the right directory, then you will get a "File not found"
error message unless you either use the 'cd' command to change
directory into the correct place or refer to the file by its
complete path name (e.g., '/mnt/animals/aquatic/avians/images/penguins.jpg').
This feature can be both powerful and treacherous, and you should always
make sure you are in the directory you think you are in before doing
The 'ls' command, with no arguments, lists the contents of the working directory... mostly. It gives you a listing of file and subdirectory names, with no indication which is which, and it doesn't list any file or directory whose name starts with a . (dot).
Why would anyone want a file name starting with a dot? So that it won't get listed by the 'ls' command! Dot-name files usually contain things like default parameters for certain programs, or personal preference settings, things like that. You don't have any particular need to see them so if their names start with a dot, they don't get in the way. If you do want to see them, use the '-a' option of 'ls', like this:
% ls -a
(This, incidentally, is the way a command with options always looks-- the command name, followed by a space, followed by a minus sign and the letter code of the option. You'd pronounce this "ell ess minus a.")
The most important of the dot-files is '.cshrc', which lives in your home directory. (That's the directory the system puts you in when you log in.) This file contains parameters for the "C-shell", which is the program that the operating system runs all the time to read what you type on the keyboard, interpret commands, and so forth. Once you learn to use a text editor, you should look at this file. I highly recommend adding the following lines (somewhere near the end) if they aren't there already:
alias t cat alias ls ls -F alias rm rm -i alias cp cp -i alias mv mv -i
The 'cat' command just dumps a file onto the screen. This is very
un-mnemonic so the first line defines a new command 't' to type
the file. Remember that it's your job to know that only ASCII (in PC
language, "plain text") files make any sense when you 't' them; if you
't' an executable file or a binary data file you are in for a surprise.
The remaining 'alias' lines redefine the 'ls', 'rm', 'cp', and 'mv'
commands so that they are always executed with the given options, even
when you just type the regular command name. 'ls -F' is just like 'ls'
except that it marks directories with a slash (/) right after the name,
executable files with an asterisk (*), and symbolic links (which you don't
need to know about right now) with an at-sign (@). The remaining 3
commands remove, copy, and move files respectively, and the 'aliases'
make them run in 'interactive' mode, so that the system will ask you
to verify that you actually want to delete or over-write a file. Once
you modify your '.cshrc' file this way, these commands will
automatically be set up for you every time you log in.
You can probably see that working in a Unix environment requires a slightly
different way of thinking about files and programs. Still, the DOS user
interface evolved from Unix, and Windows evolved from DOS, so perhaps
it's not as different as it could be. Hopefully, you're now sufficiently
prepared that you can dive into one of the many good beginners guides
and Unix tutorials, a few of which are linked below. Good luck!
A Summary of Basic Unix Commands, from the Society of Physics Students
"Unix is a Four Letter Word", by Chris Taylor
Unix Tutorial and Reference Guides, from Unix-Manuals.com
Unix Tools for Code Development, by the author; not exactly a Unix guide, discusses the basics of compiling and running Fortran programs under Unix. Includes an emergency introduction to the 'vi' editor.
Last revised 2008 April 1