The Shell

The Shell

As I mentioned in the section on introduction to operating systems, the shell is essentially a user’s interface to the operating system. The shell is a command line interpreter, just like other operating systems. In Windows you open up a “command window” or “DOS box” to input commands, which is nothing other than a command line interpreter. Through it, you issue commands that are interpreted by the system to carry out certain actions. Often, the state where the system is sitting at a prompt, waiting for you to type input, is referred to (among other things) as being at the shell prompt or at the command line.

For many years before the invention of graphical user interfaces, such as X-Windows (the X Windowing System, for purists), the only way to input commands to the operating system was through a command line interpreter, or shell. In fact, shells themselves were thought of as wondrous things during the early days of computers because prior to them, users had no direct way to interact with the operating system.

Most shells, be they under DOS, UNIX, VMS, or other operating systems, have the same input characteristics. To get the operating system to do anything, you must give it a command. Some commands, such as the date command under UNIX, do not require anything else to get them to work. If you type in date and press Enter, that’s what appears on your screen: the date.

Some commands need something else to get them to work: an argument. Some commands, like mkdir (used to create directories), work with only one argument, as in mkdir directory_name. Others, like cp (to copy files), require multiple arguments, as in

cp file1 file2

In many cases, you can pass flags to commands to change their behavior. These flags are generally referred to as options. For example, if you wanted to create a series of sub-directories without creating every one individually, you could run mkdir with the -p option, like this:

mkdir -p one/two/three/four

In principle, anything added to the command line after the command itself is an argument to that command. The convention is that an option changes the behavior, whereas an argument is acted upon by the command. Let’s take the mkdir command as an example:

mkdir dir_name

Here we have a single argument which is the name of the directory to be created. Next, we add an option:

mkdir -p sub_dir/dir_name

The -p is an option. Using the terminology discussed above, some arguments are optional and some options are required. That is, with some commands you must always have an option, such as the tar command. Some commands don’t always need to have an argument, like the date command.

Generally, options are preceded by a dash (-), whereas arguments are not. I’ve said it before and I will say it again, nothing is certain when it comes to Linux or UNIX, in general. By realizing that these two terms are often interchanged, you won’t get confused when you come across one or the other. I will continue to use option to reflect something that changes the command’s behavior and argument to indicate something that is acted upon. In some places, you will also see arguments referred to as “operands”. An operand is simply something on which the shell “operates”, such as a file, directory or maybe even simple text.

Each program or utility has its own set of arguments and options, so you will have to look at the man-pages for the individual commands. You can call these up from the command line by typing in

man <command_name>

where <command_name> is the name of the command you want information about. Also, if you are not sure what the command is, many Linux versions have the whatis command that will give you a brief description. There is also the apropos command, which searches through the man-pages for words you give as arguments. Therefore, if you don’t know the name of the command, you can still find it.

Arguments (whether they are options or operands) which are enclosed in square brackets ([ ]) are optional. In some cases, there are optional components to the optional arguments, so you may end up having brackets within brackets.

An ellipsis (…) Indicates that the preceding arguments can be repeated. For example, the ls command can take multiple file or directory names as arguments as well as multiple options. Therefore, you might have a usage message that looks like this:

ls [OPTION] … [FILE] …

This tells us that no options are required, but if you wanted you could use multiple options. It also tells us that no file name is required, but if you wanted you could use multiple ones.

Words that appeared in angle brackets (< >) or possibly in italics in the printed form, indicate that the word is a place holder. Like in the example below:

man <filename>

Many commands require that an option appear immediately after the command and before any arguments. Others have options and arguments interspersed. Again, look at the man-page for the specifics of a particular command.

Often, you just need a quick reminder as to what the available options are and what their syntax is. Rather than going through the hassle of calling up the man-page, a quick way is to get the command to give you a usage message. As its name implies, a usage message reports the usage of a particular command. I normally use -? as the option to force the usage message, as I cannot think of a command where -? is a valid option. Your system may also support the –help (two dashes) option. More recent versions of the various commands will typically give you a usage message if you use the wrong option. Note that fewer and fewer commands support the -?.

To make things easier, the letter used for a particular option is often related to the function it serves. For example, the -a option to ls says to list “all” files, even those that are “hidden”. On older versions of both Linux and Unix, options typically consisted of a single letter, often both upper and lowercase letters. Although this meant you could have 52 different options it made remembering them difficult, if they were multiple functions that all began with the same letter. This means that in a number of cases, the developers had to make a decision as to which letter stood for which option.

To make things easier, when using the short options, multiple options can either be placed separately, each preceded by a dash, or combined. For example, both of these commands are valid and have the exact same effect:

ls -a -l

ls -al

In both cases you get a long listing (-l) which also included all of the hidden files (-a).

Newer versions of commands typically allow for both single letter options and “long options” which use full words. For example, the long equivalent of -a would be –all. Note that the long options are preceded with two dashes because it would otherwise be indistinguishable from the -a followed by two -l options.

Note that saying “newer” might be somewhat confusing. As of this writing (Dec 2006), I cannot think of any current distribution which has no commands that support long options. Therefore it would probably better to say, that with older distribution you may find that long options are not supported.

Although it doesn’t happen too often, you might end up with a situation where one of the arguments to your command starts with a dash (-), for example a file name. This “normally” doesn’t happen, but you can run into problems if it does. Since options typically start with a dash, the shell cannot figure out that it is an argument and not a long line of options. Let’s assume that some application created a file named “-jim“. If I wanted to do a simple listing of the file, I might try this:

ls -jim

However, since the shell first tries to figure out what options are being used before it shows you the listing, it thinks that these are all options and gives you the error message:

ls: invalid option — j Try `ls –help’ for more information.

You can solve this problem with some commands by using two dashes to tell the command that what follows is actually an argument. So to get the listing in the previous example, the command might look like this:

ls — -jim

A frequently overlook aspect of working with the shell are resource limitations, which can prevent problems for improperly implemented programs. One example, is the maximim number of files that a shell can have open at one time. This usually defaults to 1024, which can seem like a lot, but I have run across applications were where even this was too few. To see the currently set values, simply run ulimit -a, which might show you something like this:

core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited pending signals (-i) 1024 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 4096 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited

One important aspect is that each of these values has both a soft limit and a hard limit. A user can decreate the soft limit, as well as adjust the respective soft limit up to the respective hard limit. To go beyond the hard limit, the root must make changes to the file /etc/security/limits.conf.