The ECN No Name Newsletter is no longer being published. This is an archived issue.

Solaris: Search Path Changes

NO NAME NEWSLETTER Article, April 1994

David Curry

The following article is a reprint of a portion of ECN 199-E, Migrating To Solaris And The Common Unix Environment. To obtain a copy of the complete document, please contact your site specialist.

The search path is the list of directories in which your shell looks for commands to execute. The default search path is set for you automatically by the system, and given to your shell when you log in. You can use your shell startup files (.profile, .cshrc, .login) to add directories to, delete directories from, and rearrange the order of your search path.

The changes described in this section will become effective as follows:

Existing Solaris systems: These changes will become effective on systems currently running Solaris when they are upgraded to Solaris 2.3 over the Christmas 1993 break.

SPARC SunOS systems: These changes will become effective on SPARC (Sun-4) systems running SunOS when they are converted to Solaris in Summer 1994.

The Common UNIX Environment Search Path

This section describes the various elements of the CUE search path. The discussion is divided into four parts-one for each of the three layers of the CUE, and one for unsupported software.

The UNIX Operating System Software Layer

The UNIX Operating System Software layer of the CUE contains the commands offered by each vendor's UNIX implementation. In this case, the vendor is Sun Microsystems, and the UNIX implementations will be SunOS and Solaris. On SunOS, there are two directories in this layer, /usr/bin and /usr/ucb. On Solaris, there is only one directory in this layer, /usr/bin. The commands in this layer are the ``standard UNIX commands,'' such as vi, cat, ls, rm, mv, sh, csh, and so forth.

In the past, the ECN staff has replaced certain commands in this layer with local versions of the same commands. While this at times provides added functionality, it makes our systems incompatible with other UNIX systems. Beginning with the migration to Solaris, the ECN staff will not replace commands in this layer with local versions (except in three cases where it is unavoidable). Instead, the local versions of these commands will be placed in the Common UNIX Environment Software layer, which precedes the UNIX Operating System Software layer in the default search path. In this way, ECN users will still receive the added-functionality version of the command, but the standard version of the command will be available to those who need it.

The Common UNIX Environment Software Layer

For many years, the ECN staff has installed ECN-supported software (both locally-developed and public domain) in the directory /usr/ecn. This practice began long before there was a standard in the UNIX community for storage of local software, and has been carried forward for reasons of backward compatibility. The ECN staff has also had for some time a practice of installing site-specific software in the directories /usr/local and /usr/custom. Unfortunately, the non-standard nature of these practices has become a major problem when installing software developed outside the ECN. The practices are also confusing to users who come from other UNIX sites, since the UNIX community as a whole uses different conventions.

In order to provide a more standard environment, one that is consistent with established conventions in the UNIX community, the Common UNIX Environment Software layer specifies that locally-maintained software (both locally-developed and public domain) will be installed in the directory /usr/local/bin. (Basically, this means that /usr/ecn is being renamed /usr/local/bin.)

Because the above change conflicts with the current use of the name /usr/local, and in order to make the distinction between CUE -supported and site-specific software more clear, site- specific software is now contained in the Site-Specific Software layer, described shortly.

Locally-Supported Software

At the present time, the list of locally-supported software that will be contained in the CUE is still being finalized. As of January 1994 the CUE /usr/local/bin directory contained the following programs:

Pnews        flex        merge        project    shar
Rnmail       flost       mh           protoize   strip7
X11R5        g++         mk           ps4014     sx
archive      gcc         mkcmd        ps630      sz
bison        gdb         newsetup     pscat      talk
checknews    ghostview   newsgroups   pscatmap   tclhelp
checn        gr          nn           psdit      tclsh
chfn         gs          nnadmin      psfig      tclshx
chkacct      ident       nncheck      pslpr      tip
chsh         inews       nngoback     psnup      tn3270
ci           kermit      nngrab       psplot     turnin
cleanscript  labstat     nngrep       psroff     unprotoize
co           learn       nnpost       ptroff     unrm
colcrt       less        nnquery      qplot      webster
connect      lesskey     nnstats      rb         wish
cue          lname       nntidy       rc         wishx
des          lprint      nnusage      rcs        wxp_wx
emacs        lwah        pbm          rcsmerge   wxproot
enscript     lwinfo      perl         readnews   wxptxt
etags        lwpages     ph           rlog       xstart
fax          lwpasswd    phone        rn
faxq         lwq         plot3d       rx
faxrm        mailbox     policy       rz
finger       maketd      postnews     sb

Within the /usr/local/bin directory are four subdirectories: /usr/local/bin/X11R5

This directory contains the MIT X Window  System,  Version  11
Release 5 software.
/usr/local/bin/dwb
This directory contains the Documentor's Workbench versions of
the troff, eqn, tbl, pic, and grap programs.
/usr/local/bin/mh
This directory contains the RAND Mail Handler  (MH)  software,
version 6.8.3.
/usr/local/bin/pbm
This  directory  contains  the  PBMPLUS   image   manipulation
programs.

These software packages, because of the large number of commands in each, have been placed into subdirectories, since we do not expect everyone to use them. If you would like to make use of one or more of these packages, see the section on customizing your search path, later in this chapter.

CAUTION

The ECN version of the rm command that copies files into /zap will not be a part of the CUE. Instead, we will be using the

rm

and unrm commands developed by the Computer Center to provide the same functionality (saving copies of deleted files for later retrieval in case you make a mistake). Until this software is ported to Solaris, you may wish to alias the rm command to

rm -i,

which will prompt you for conformation before removing any files.

NOTE

The current /usr/ecn directory contains a number of programs that are obsolete or simply no longer used. These commands have not been included in the CUE. In addition, a number of commands which have not been supported by the ECN in the past, but were supported or developed by the Computer Center, are now a part of the CUE. If you encounter a program that is in /usr/ecn on the SunOS systems that is not present in the CUE, please contact your site specialist. He or she can help you determine whether there is a replacement program, a workaround, or if the program needs to be added to the CUE.

Third-Party Software

The Common UNIX Environment Software layer specifies that third- party (commercial) software will be installed in the directory /usr/opt/bin. The list of third-party software that will be a part of the CUE has yet to be determined. However, in order to begin the changeover to the CUE scheme, the ECN staff has installed the third-party software packages currently available for Solaris in /usr/opt/bin. As of the date on the cover of this document, the following third-party packages have been installed in /usr/opt/bin:

Abaqus       Island Draw       Lotus 1-2-3      SPARCWorks
Ansys        Island Equation   MATLAB           Sun C
AutoCAD      Island Paint      Maple            Sun C++
CodeCenter   Island Table      Mathematica      Sun FORTRAN
Frame Maker  Island Write      ObjectCenter     Sun Pascal
IMSL                                            Word Perfect

As the Solaris versions of other packages are received, they will be installed in /usr/opt/bin as well.

The Site-Specific Software Layer

The ECN staff maintains two directories, /usr/local and /usr/custom, for the installation of site-specific software. This software is installed at one or two sites, but is not available at other sites. For example, the School of Electrical Engineering maintains a command called eeph that prints phone numbers and office assignments for EE faculty, staff, and graduate students. This command is only available on EE systems. In part because the /usr/local name is now used for other purposes (see the previous section), and in part to provide new functionality, the Site- Specific Software layer specifies that site-specific software will be installed in /usr/site//bin, where is, usually, the official university abbreviation for the site. The currently defined values are:

   School
  ______________________________________________
aae      Aeronautics and Astronautics
agen     Agricultural Engineering
che      Chemical Engineering
ce       Civil Engineering
ee       Electrical Engineering
engr     Freshman Engineering
ie       Industrial Engineering
ide      Interdisciplinary Engineering
mse      Materials Engineering
me       Mechanical Engineering
nucl     Nuclear Engineering

Thus, for example, on a system owned by the Agricultural Engineering department, the contents of the SunOS /usr/local and /usr/customdirectories would be merged and stored in /usr/site/agen/bin.

When you log in to a system, the /usr/site//bin directory for the site that owns that system will be placed into your search path automatically. In addition, beginning in Summer 1994, the system will maintain a list of other sites' bins that you would like to use when you log in, and add those to your path automatically as well. For example, if you are a Mechanical Engineering student, but you are also taking a class in Chemical Engineering, you might want to use the special Chemical Engineering programs on a workstation in the Mechanical Engineering building. You will be able to tell the system this, and it will automatically make these commands available to you.

Unsupported Software

For a few years now, the ECN staff has allowed ``regular users'' to make software available via the /usr/unsup directory. This software is not supported by the ECN staff, but rather by individual users (faculty, staff, and students). In order to conform to the new structure of other directories in the search path, this software will now be stored in the directory /usr/unsup/bin. (Basically, /usr/unsup will just be called /usr/unsup/bin instead.) In addition, because the /usr/unsup/bin directory will be offered on all CUE systems, the software in this directory will be available to you on both ECN and PUCC systems.

Since the ECN and PUCC staffs do not support the software in /usr/unsup/bin, this directory will not be part of the standard search path on CUE systems. This is a notable change - /usr/unsup is a part of the standard search path on ECN SunOS systems. The change is being made because there has been a great deal of confusion about who supports the material in /usr/unsup, and many people have been relying on software over which the ECN staff has no control. By taking /usr/unsup/bin out of the standard search path, it becomes more evident that the software in this directory is not supported nor endorsed by the ECN or PUCC staffs.

The Complete Search Path

To summarize the material in the previous sections, the standard search path provided by all CUE systems when you log in (before any commands in your .profile, .cshrc, or .login are executed) will be:

/usr/local/bin:/usr/opt/bin:/usr/bin:\
/usr/site/sitename/bin:.

on Solaris systems, and
/usr/local/bin:/usr/opt/bin:/usr/ucb:\
/usr/bin:/usr/site/sitename/bin:.

on SunOS systems. In both of these examples, sitename is the name of the site (school) that ``owns'' the particular system you are using.

When the ability to add additional sites' bins to your search path becomes available in Summer 1994, those directories will be placed into the search path immediately following the /usr/bini directory.

Customizing Your Search Path

Most users simply accept the default search path, and do not change it themselves. However, if you are one of those people who does customize your search path, you may have to edit your .profile, .cshrc, or .login file and make corrections for the new search path offered by Solaris and the CUE. The ECN staff recommends that rather than listing the directories of the default path explicitly in your startup files, you use the value of the default path in a symbolic form. In this way, if the default path changes some time in the future, you will not have to make any changes to your environment.

Example:. To add the directory /usr/unsup/bin to the end of your path, the following syntax is recommended:

Bourne/Korn shell (.profile):
  PATH=$PATH:/usr/unsup/bin
export PATH
C Shell (.cshrc/.login):
  set path = ( $path /usr/unsup/bin )

Example: To add the directory ~/bin (your own private directory of programs) to the front of your path, the following syntax is recommended:

Bourne/Korn shell (.profile): PATH=$HOME/bin:$PATH export PATH C Shell (.cshrc/.login): set path = ( ~/bin $path )
Example: To add both ~/bin to the front of your path and /usr/unsup/bin to the end of your path, the following syntax is recommended:

Bourne/Korn shell (.profile): PATH=$HOME/bin:$PATH:/usr/unsup/bin export PATH C Shell (.cshrc/.login): set path = ( ~/bin $path /usr/unsup/bin )
If you have any questions about customizing your search path, contact your site specialist.

Customizing Your Manual Page Path
The man command, which is used to display the on-line manual pages for UNIX commands, files, and library routines, can be given a list of directories in which to search for manual pages, much like your shell can be given a list of directories in which to search for commands.
Manual pages are stored in the following directories on CUE systems:
/usr/man Manual pages for the UNIX Operating System Software layer. /usr/local/man, /usr/opt/man Manual pages for the Common UNIX Environment Software layer. /usr/site//man Manual pages for the Site-Specific Software layer.
Beginning in Summer 1994, CUE systems will set the manual page search path to include all four of these directories automatically. However, in the interim, you will need to set this value yourself, because the currently-installed software does not do it for you.
To set your manual page search path, use a command such as the following:

Bourne/Korn shell (.profile): MANPATH=/usr/opt/man:/usr/local/man:/usr/man:\ /usr/site/sitename/man export MANPATH C Shell (.cshrc/.login): setenv MANPATH /usr/opt/man:/usr/local/man:\ /usr/man:/usr/site/sitename/man where sitename is the name of the site whose systems you normally use.

You may also wish to add the following directories to your manual page search path, depending on your needs:
/usr/openwin/share/man Manual pages for the OpenWindows window system commands. /usr/local/X11R5/man Manual pages for the MIT X Window System, Version 11 Release 5 software. /usr/unsup/man Manual pages for the unsupported software.
To do this, we recommend that you create a second line in your startup file that appends these directories to the default manual page search path you defined above. This way, when the software is modified to set the default manual page search path automatically, you can just delete the first line described above from your startup file, and everything will continue to work as you expect.

Example: To add /usr/unsup/man to your manual page search path, the following syntax is recommended:
Bourne/Korn shell (.profile): MANPATH=/usr/opt/man:/usr/local/man:\ /usr/man:/usr/site/sitename/man MANPATH=$MANPATH:/usr/unsup/man export MANPATH C Shell (.cshrc/.login): setenv MANPATH /usr/opt/man:/usr/local/man:\ /usr/man:/usr/site/sitename/man setenv MANPATH $MANPATH:/usr/unsup/man

Configuring Your Environment
Since you will be sharing your home directory between SunOS and Solaris systems, particularly between now and Summer 1994, you may wish to configure your environment (.profile, .cshrc, .login, etc.) so that it will work on either version of the operating system. Here is one way to do this:

Bourne/Korn shell (.profile): if [ -x /usr/5bin/uname ]; then version=`/usr/5bin/uname -s -r` else version=`/usr/bin/uname -s -r` fi case $version in SunOS 5.*) commands for Solaris... ;; SunOS 4.*) commands for SunOS 4.1... ;; esac C shell (.cshrc/.login): if ( -x /usr/5bin/uname ) then set version=`/usr/5bin/uname -s -r` else set version=`/usr/bin/uname -s -r` endif switch ( "$version" ) case "SunOS 5.1": case "SunOS 5.2": case "SunOS 5.3": case "SunOS 5.4": commands for Solaris... breaksw case "SunOS 4.1.1": case "SunOS 4.1.2": case "SunOS 4.1.3": commands for SunOS 4.1... breaksw endsw

Managing a Personal ``Bin'' Directory
If you have a personal ``bin'' directory, you will need to recompile the programs there for Solaris. Although many programs will run in binary compatibility mode, they suffer a performance penalty for doing so. However, please note that while Solaris can run programs compiled on SunOS, SunOS cannot run programs that have been compiled on Solaris. This means that, if you have a personal ``bin'' directory, you will have to configure it for multiple architectures.
One way to do this is to make subdirectories in your ``bin'' directory, one for each architecture. For example, you might have subdirectories called sun3, sun4, and sun4.solaris. You can use the uname -m command in your .profile, .cshrc, or .login to obtain the processor type (``sun3'' or ``sun4'') and the uname -s -r command to handle the operating system version. For example:
Bourne/Korn shell (.profile): if [ -x /usr/5bin/uname ]; then version=`/usr/5bin/uname -s -r` else version=`/usr/bin/uname -s -r` fi case $version in SunOS\ 5.*) bin=$HOME/bin/sun4.solaris commands for Solaris... ;; SunOS\ 4.*) bin=$HOME/bin/`uname -m` commands for SunOS 4.1... ;; esac PATH=$bin:$PATH export PATH C Shell (.cshrc/.login): if ( -x /usr/5bin/uname ) then set version = `/usr/5bin/uname -s -r` else set version = `/usr/bin/uname -s -r` endif switch ( "$version" ) case "SunOS 5.1": case "SunOS 5.2": case "SunOS 5.3": set bin = ~/bin/sun4.solaris commands for Solaris... breaksw case "SunOS 4.1.1": case "SunOS 4.1.2": case "SunOS 4.1.3": set bin = ~/bin/`uname -m` commands for SunOS 4.1... breaksw endsw set path = ( $bin $path )
There are other, equally valid ways to do this - the above is just one suggested method.

webmaster@ecn.purdue.edu
Last modified: Saturday, 13-Sep-97 02:14:35 EST
HTML