Introduction to the Basic Unix Shell Commands 

The Unix Shell and the Unix Command Line:

The shell is that portion of Unix that handles the command line by which you enter commands. (Unix always has a shell; it doesn't always have a GUI — a graphical user interface — as a Mac or Windows machine does.)  You run other, more interesting programs by asking the shell to run them for you.  They may run for hours but when they're done, control of the keyboard and display returns to the shell.  So the shell is the "top level" program you deal with on a Unix system.  You command the shell to do things for you (like run some other program) by typing and entering commands from the keyboard.  To enter a command to the shell, you must see a prompt and a blinking cursor. That is your cue (prompt) that the shell  is ready for you to start typing. If you don't see a shell prompt, some other program (that your shell started for you at your request) is still running and is connected to your keyboard instead of the shell.

Since most commands operate on (do things to or with) files, you may also have to tell the command which file(s) to use; so file names (and sometimes other data you type on the command line) are often referred to as arguments to commands — don't ask me where that word "argument" comes from in this context (I don't actually know, to tell you the truth).  Thus, commands typically take the form  commandName fileName, e.g.,  gcc hw3.c    There must be at least one space between the two names. 

  • In Unix, anywhere a blank is required or allowed, multiple blanks or tabs are also allowed and usually anywhere one or more whitespaces (blanks or tabs) are allowed, at least one is required.  So if some documentation told you to enter xxx yyy,   you could enter either xxx yyy   or  xxx   yyy,   but not  xxxyyy.
  • A few commands don't  need an explicit file name — they either never need a file name at all or supply a sensible default for you if you don't enter one explicitly.    (Unix and the shell will do a lot for you by default.)

When you want the shell to execute the command you've typed, hit the "Enter" or "Return" key on your keyboard — after typing the file name(s) for any argument(s) first.  Nothing will happen until you "Enter" the command you've typed.  Until you get more advanced, your entire command (the command name itself followed by the argument(s) you want to give it, if any) must all fit on one line that you must "Enter" only after you type the entire line the way you want it.  Note:

  • The Unix shell may automatically "wrap" the display of the characters you are typing if and when it hits the visual end of a line within some window or display device (so it looks like there was an "Enter" entered); but you can't do that for yourself. Once you hit the "Enter" key, the command line is gone and Unix will try to execute it "as is".
  • Other Unix programs (that you yourself must have started by issuing an earlier command to the shell) may or may not accept commands from you from the keyboard (most compilers won't, for example), and those that do may or may not require you to hit the "Enter" key.  See the program named "more", below, for example.  It is controlled by individual keystrokes without any other explicit "entry" action required. Each program has its own rules and conventions. 

More about prompts.  Sometimes, like when you're editing a file, your keystrokes will go to another program, not the shell.  If you're editing, for example, you're typing input to the editor.  (You had to command the shell to run the editor for you, but once the editor started running, you would be typing inputs to it and not to the shell.)   Some programs, like the shell, display prompts for you; some don't — depends on what the program's for and whether or not it really wants any keyboard input from you.  A compiler typically doesn't, for example — all your input to the compiler comes from a file you somehow created previously, probably using an editor.  So a compiler provides no prompt whatsoever and if you type on your keyboard while the compiler is running, the keystrokes probably just get ignored (by the compiler, they might get saved and fed as input to the shell after the compiler is done, however).  An editor accepts keyboard  input from you but displays no prompt — it just accumulates your keystrokes in a buffer and displays them to let you edit them.

Any program that does prompt you for keyboard input will usually try to pick a distinctive prompt so that you'll be able to tell exactly which program you're talking to.  As I said earlier, when discussing commands, each program has its own rules and conventions — this is true both for how it is controlled as well as what type of prompt it displays (if any).  That's why I and other Unix authors sometimes refer to the "shell prompt"  to distinguish it from the prompts provided by other prompting programs.  There's nothing all that special about the shell; it's just another program as far as the rest of Unix is concerned — a particularly important, useful, and interesting program, but still just another program.  (The purpose of the shell program is to provide you a command line interface to the rest of the Unix system.) 


Most shell commands can in fact do several different things or do one thing in several different ways so they accept options,  indicated on the command line by a dash. But they're just that — options — so there's almost always a sensible default if you choose not to invoke the option.  Many of the options are pretty useful, however, so you'll want to know a little about how to find out about them and how to use them.  Here's an example:  man -k print  executes the man command with an option of  'k', for keyword and it will be quite a bit different than man print, which invokes man with no options, only the one argument print.  (See the write-up for the man command, below, for what that -k option means.)  Note: You'll use the man command to get the details on all the options available for any of the commands listed below or indeed any standard command in the Unix system. man stands for "manual", as in the reference manual.  There is no "help" command in Unix; man is the equivalent.

Basic  Commands: 

  • Many/most Unix commands, if entered with no arguments at all, will display a "usage" summary for the command line — i.e., a very brief description of what arguments need to be added to just the bare command name to get anything at all to happen.  But remember, some commands will actually provide a complete set of defaults under these circumstances (no arguments) and hence actually do something.  Usually that will be something harmless; but if you're not sure, it's obviously safer to use the man command first.

There's a huge man page for this and it's even available in HTML, but it's vast overkill.  All you really need to know is:

ctime.c: In function `main':
ctime.c:16: parse error before `='

The first entry on the first line, before the colon, is the name of the file being compiled (ctime.c, in this example).  The rest of that first line tells you which function in that file the error messages pertain to.  Subsequent lines give you the line numbers (of the file, not the function) containing the errors, plus as much information as the compiler can manage about each error itself.  (Usually not too much — gcc is freeware; one of the reasons people spend money on more expensive compilers is to get better diagnostic help.) 

Entering just the command  gcc --help will give you a very brief overview of some of the most important of the hundreds of complicated options that are still totally irrelevant to an undergraduate programming class.


If you're having trouble visualizing the workings of script, here's a link to another URL with some pictures in it.

This page last changed 3 Sep 2010 by Dr. M.S. Jaffe