Running Commands

Team-Fly    

Solaris™ Operating Environment Boot Camp
By David Rhodes, Dominic Butler
Table of Contents
Chapter 5.  Shells


The main purpose of the shell is to run commands and programs. UNIX commands and programs generally take the following syntax:

 command options parameters 

The command is the name of the file as it appears in the directory. The options generally change the way the command will function and will usually consist of single letters preceded by a minus sign. The parameters could be anything, such as filenames or user names.

All commands have a name (otherwise they would not exist), but they don't all take options and they don't all take parameters. Even those that do take options and/or parameters (which is most) don't always have to be supplied with them. (The Solaris man pages give the usage of all Solaris commands. It is recommended that you install them on at least one of your systems.)

To execute a command, the shell must know in which directory the command is stored on the hard disk. One way to tell the shell this is to provide the full path of the command when you use it. For example, the command ls can be found in the directory /bin. So, if you type "/bin/ls" at the shell prompt, the shell knows exactly where to find the command and will run it for you.

This is not very practical because users don't like typing more than they have to. Also, there are many directories containing commands on a system and people cannot be expected to remember exactly which directory contains which command.

The way we get around this is mentioned in Table 5.1, "Environment Variables," on page 102, and makes use of the $PATH variable.

On our systems we have set the PATH variable for normal users as follows:

 export PATH="/bin:/usr/sbin:/usr/local/bin:" 

This means that each time you type in a command the shell will look for it in /bin and if it is found there it will be run. If it isn't, the shell will look in the next directory in the list (/usr/sbin) and so on.

In the example above, the PATH ends with a colon. A colon at the beginning or the end (or two colons together in the middle) of the PATH represent the current directory. (You could also use a dot to represent your current directory.) In the example above, if the shell has not found your command in the named directories, it will look in the current directory. The shell does not look in your current directory by default so if you don't include it in your PATH you will not be able to run commands located there if you don't provide their path names.

It is often useful to have a different PATH for the root user as there are certain commands that are normal for root to run, but should not be accessible to ordinary users. For example:

 export PATH="/etc:/bin:/usr/sbin:/usr/local/bin:/usr/local/utilities/bin" 

We have added the directory /etc to the start of the root PATH as it is traditionally the directory that contains administrative commands. We have also added /usr/local/utilities/bin as it is the directory we have chosen to store the administrative scripts we have developed to help manage our servers. The other difference (which you have noticed, hopefully) is that we do not include the current directory. This is because root has the power to do anything on the server so it is important that when root runs a command the expected command runs. Having the current directory included in the root PATH could mean that the wrong command could be run by mistake due to a file with the same name existing in the current directory. This is not just preventing mistakes, since a malicious user could write a script, give it the same name as an administrative command, and then leave it in various directories in the hope that one day root may accidentally run it. This may seem farfetched, but this sort of thing has happened. In general, malicious users (or hackers) will want to try and execute something as root (whatever their ends); this is one way that should not be left open.

Hopefully, this is fairly straightforward, but as with most areas of UNIX there is more to it than that.

In this case, the "more to it" is that there are a number of commands that exist in more than one directory. In most cases, these commands will perform the same function and produce the same output, but this is not always so. The main reason for this is compatibility with earlier UNIX variants. Solaris has been made as compatible as possible with older versions and has specific bin directories to hold commands that are compatible with specific versions. For example, the directory /usr/ucb contains commands that are compatible with those found in the Berkeley version of UNIX (known as BSD), while /usr/sbin contains those that are compatible with UNIX System 5 Release 4 (UNIX SVR4). Both these directories contain a df command; although both display the current filesystem usage, the output is different and they take different options.

With a PATH set to the value above, typing df would always cause the SVR5 version to run since /usr/ucb is not included in the PATH. If we included /usr/ucb into the PATH, its position in the PATH will decide which version of df actually gets run.

If you want to find out which version of a command your shell is going to run, you can use the which command:

 $ which df /bin/df $ 

If you try this with a number of different commands, you will begin to get an idea of where different commands reside.

A similar command to which is called whereis. This command comes from BSD so if your PATH does not include /usr/ucb you will not be able to run it unless you type the full path name. You can add /usr/ucb to your PATH by typing:

 $ export PATH="$PATH:/usr/ucb" $ echo $PATH /bin:/usr/sbin:/usr/local/bin::/usr/ucb $ 

The order for the shell to search the PATH is now:

  1. /bin

  2. /usr/sbin

  3. /usr/local/bin

  4. current directory

  5. /usr/ucb

The command whereis is similar to which, but instead of just displaying the first occurrence of the command you are looking for, it displays all of them:

 $ whereis df df: /usr/bin/df /usr/sbin/df /usr/ucb/df $ 

There are three df commands listed, but the first two are identical. (Note: The reason the output displays /usr/bin/df instead of /bin/df is because /bin is linked to /usr/bin. Links are discussed in Chapter 6, "The Filesystem and Its Contents.")

Some commands don't exist in directories, but are actually built into the shell. Some of the most commonly used commands are built in, such as cd and echo. The which command won't tell us if a command is built in, but the command type will:

 $ type cd cd is a shell builtin $ type type type is a shell builtin $ 

On your Solaris system you may find that if you use which with a command that is built into the shell you get an unexpected result:

 $ which type /bin/type $ 

This is because the built-in commands each have a version in /bin. But in all cases the version in /bin is simply a shell script that calls the built-in version (as shown below):

 #!/bin/ksh # # Copyright © 1995 by Sun Microsystems, Inc. # cmd=`basename $0` $cmd "$@" 

(Note: $0 represents the name of the script (in this case type); $@ represents all the parameters which have been supplied to the script.)

You will see that the directory /bin contains a number of scripts with the same name as a command built in to the Korn Shell. If you look in any of them you will see that they are all identical. The reason they exist is to enable you to run the Korn Shell built-ins even if you are not actually using the Korn Shell (thanks to the first line of the script).


    Team-Fly    
    Top
     



    Solaris Operating Environment Boot Camp
    Solaris Operating Environment Boot Camp
    ISBN: 0130342874
    EAN: 2147483647
    Year: 2002
    Pages: 301

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net