How Linux Works: What Every Superuser Should Know

16.2 Shell Startup File Elements

What goes into a shell startup file? Some things may seem obvious, such as the path and a prompt setting. But wait, what exactly should be in the path, and what does a reasonable prompt look like? And how much is too much to put in a startup file?

The next few sections outline the essentials of a shell startup file, covering the command path, manual page path, prompt, aliases, and permissions mask.

16.2.1 The Command Path

The most important part of any shell startup file is the command path. The path should cover the directories that contain every application of any general interest to a regular user . At the very least, the path should contain these components , in this order:

/usr/local/bin /usr/bin /usr/X11R6/bin /bin

This order ensures that you can override standard default programs with site-specific program variants located in /usr/local .

It's important to make every general-use program on the system available through one of the directories listed above (for example, using the Encap system described in Section 9.4). If the general-use programs are located in more than just these four directories, it probably means that your system is getting out of control. Don't change the path in your user environment to accommodate a new system directory. In fact, in the interest of minimizing the number of directories in the command path, some administrators prefer to fold the programs in /usr/X11R6/bin into /usr/local/bin or /usr/bin with the help of symbolic links or a different installation prefix.

Many users use a bin directory to store their own shell scripts and programs, so you may want to add this to the front of the path:

$HOME/bin

If you are interested in systems utilities (such as traceroute , ping , and lsmod ), add the sbin directories to your path:

/usr/local/sbin /usr/sbin /sbin

Adding Dot (.) to the Path

There is one small but controversial command path component to discuss: the dot. Placing a dot (.) in your path allows you to run programs in the current directory without using ./ in front of the program name . This may seem convenient when writing scripts or compiling programs, but it is a bad idea for two reasons:

• It can be a security problem. You should never put a dot at the front of the path. For example, an attacker could put a Trojan horse named ls in an archive distributed on the Internet. Even if a dot is at the end of the path, you are still vulnerable to typos such as sl .

• It is inconsistent and can be confusing. A dot in the path can mean that a command's behavior can change according to the current directory.

16.2.2 The Manual Page Path

Your manual path (the MANPATH environment variable used by man ) should match your command path, except that each directory in the manual page path variable should end in a /man directory rather than /bin .

Here is the manual page path that corresponds to the command path listed in Section 16.2.1:

/usr/local/man:/usr/man:/usr/X11R6/man:$HOME/man

16.2.3 The Prompt

Avoid a long, complicated, useless prompt. For whatever reason, many administrators feel the need to drag in everything, including the kitchen sink. Just because you can place the current working directory, hostname, username, and fancy decorations in a prompt, it doesn't mean that you should .

Above all, avoid strange characters , such as these:

{ } = & < >

Even a shell's default prompt isn't ideal. For example, the default bash prompt contains the shell name and version number, and the default tcsh prompt includes the hostname, the current working directory, and a > .

Here is a simple prompt setting for bash that ends with the customary $ (the traditional csh prompt ends with % ):

PS1='\u$ '

The \u is a substitution for the current username (see the PROMPTING section of the bash manual page). Other popular substitutions include the following:

• \h The hostname (the short form, without domain names )

• \! The history number

• \w The current directory (this can become somewhat long; you can display only the final component with \W )

• \$ $ if running as a user account, and # if root

16.2.4 Aliases

Among the stickier points of modern user environments is the role of aliases, a shell feature that substitutes one string for another before executing a command. At one time, these were efficient shortcuts intended to save some typing. However, aliases also have these drawbacks:

• They have balky syntax, especially when manipulating arguments.

• They are confusing; a shell's built-in which command can tell you if something is an alias, but it won't tell you where it was defined.

• They are frowned upon in subshells and non-interactive shells; they do not work in other shells .

With all of these disadvantages, it makes sense to avoid aliases whenever possible, because it's easier to write a shell script (see Chapter 7). Modern computers can start and execute shells so quickly that the difference between an alias and an entirely new command should not mean anything to you.

However, there is one particular instance where aliases do come in handy ” when you wish to alter a part of the shell's environment. You can't change an environment variable with a shell script, because scripts run as subshells.

16.2.5 The Permissions Mask

As described in Section 1.17.1, a shell's built-in umask (permissions mask) facility sets your default permissions. You should run umask in one of your startup files to make certain that any program you run creates files with your desired permissions. However, you may wonder what the best choice is, especially if you have a stand-alone machine with no other users.

The two reasonable choices break down as follows :

• 077 This is the most restrictive permissions mask; it does not give any other users access to new files and directories. This is appropriate on a multi-user system where you do not want other users to look at any of your files.

• 022 Gives other users read access to new files and directories. This is more useful than you may initially presume on a single-user system, because many daemons that run as pseudo-users would not be able to see files and directories created with the more restrictive 077 umask.