Chapter 13. User Environments

Most Linux distributions install executables for nearly all packaged software in /usr/bin. There are occasional differences, such as putting games in /usr/games and graphical applications in a separate location, so check your system’s defaults first. And make sure that every general-use program on the system is available through one of the directories listed above. If not, your system is probably getting out of control. Don’t change the default path in your user environment to accommodate a new software installation directory. A cheap way to accommodate separate installation directories is to use symbolic links in /usr/local/bin.

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

$HOME/bin

Note

A newer convention is to place binaries in $HOME/.local/bin.

If you’re 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’s a bad idea for two reasons:

It can be a security problem. You should never put a dot at the front of the path. Here’s an example of what can happen: An attacker could put a Trojan horse named ls in an archive distributed on the Internet. Even if a dot were at the end of the path, you’d still be vulnerable to typos such as sl or ks.
It is inconsistent and can be confusing. A dot in a path can mean that a command’s behavior will change according to the current directory.

13.3.2 The Manual Page Path

The traditional manual page path was determined by the MANPATH environment variable, but you shouldn’t set it because doing so overrides the system defaults in /etc/manpath.config.

13.3.3 The Prompt

Experienced users tend to avoid long, complicated, useless prompts. In comparison, many administrators and distributions drag everything into a default prompt. Your choice should reflect your users’ needs; place the current working directory, hostname, and username in the prompt if it really helps.

Above all, avoid characters that mean something significant to the shell, such as these:

{ } = & < >

Note

Take extra care to avoid the > character, which can cause erratic, empty files to appear in your current directory if you accidentally copy and paste a section of your shell window (recall that > redirects output to a file).

Even a shell’s default prompt isn’t ideal. For example, the default bash prompt contains the shell name and version number.

This simple prompt setting for bash 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(1) manual page). Other popular substitutions include the following:

\h The hostname (the short form, without domain names)
\! The history number
\w The current directory. Because this can become long, you can limit the display to just the final component with \W.
\$ $ if running as a user account, # if root

13.3.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. These can be efficient shortcuts that save some typing. However, aliases also have these drawbacks:

It can be tricky to manipulate 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 noninteractive shells; they do not work in other shells.

Given these disadvantages, you should probably avoid aliases whenever possible because it’s easier to write a shell function or an entirely new shell script. Modern computers can start and execute shells so quickly that the difference between an alias and an entirely new command should mean nothing to you.

That said, 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. (You can also define shell functions to perform this task.)

13.3.5 The Permissions Mask

As described in Chapter 2, 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. The two reasonable choices are these:

077 This mask is the most restrictive permissions mask because it doesn’t give any other users access to new files and directories. This is often appropriate on a multi-user system where you don’t want other users to look at any of your files. However, when set as the default, it can sometimes lead to problems when your users want to share files but don’t understand how to set permissions correctly. (Inexperienced users have a tendency to set files to a world-writable mode.)
022 This mask gives other users read access to new files and directories. This can be important on a single-user system because many daemons that run as pseudo-users are not be able to see files and directories created with the more restrictive 077 umask.

Note

Certain applications (especially mail programs) override the umask, changing it to 077 because they feel that their files are the business of no one but the file owner.

13.4 Startup File Order and Examples

Now that you know what to put into shell startup files, it’s time to see some specific examples. Surprisingly, one of the most difficult and confusing parts of creating startup files is determining which of several startup files to use. The next sections cover the two most popular Unix shells: bash and tcsh.

13.4.1 The bash Shell

In bash, you can choose from the startup filenames .bash_profile, .profile, .bash_login, and .bashrc. Which one is appropriate for your command path, manual page path, prompt, aliases, and permissions mask? The answer is that you should have a .bashrc file accompanied by a .bash_profile symbolic link pointing to .bashrc because there are a few different kinds of bash shell instance types.

The two main shell instance types are interactive and noninteractive, but of those, only interactive shells are of interest because noninteractive shells (such as those that run shell scripts) usually don’t read any startup files. Interactive shells are the ones that you use to run commands from a terminal, such as the ones you’ve seen in this book, and they can be classified as login or non-login.

# Command path.
PATH=/usr/local/bin:/usr/bin:/bin:/usr/games
PATH=$HOME/bin:$PATH

# PS1 is the regular prompt.
# Substitutions include:
# \u username \h hostname \w current directory
# \! history number \s shell name \$ $ if regular user
PS1='\u\$ '

# EDITOR and VISUAL determine the editor that programs such as less
# and mail clients invoke when asked to edit a file.
EDITOR=vi
VISUAL=vi

# PAGER is the default text file viewer for programs such as man.
PAGER=less

# These are some handy options for less.
# A different style is LESS=FRX
# (F=quit at end, R=show raw characters, X=don't use alt screen)
LESS=meiX

# You must export environment variables.
export PATH EDITOR VISUAL PAGER LESS

# By default, give other users read-only access to most new files.
umask 022

As described earlier, you can share this .bashrc file with .bash_profile via a symbolic link, or you can make the relationship even clearer by creating .bash_profile as this one-liner:

. $HOME/.bashrc

Checking for Login and Interactive Shells

With a .bashrc matching your .bash_profile, you don’t normally run extra commands for login shells. However, if you want to define different actions for login and non-login shells, you can add the following test to your .bashrc, which checks the shell’s $- variable for an i character:

case $- in
 *i*) # interactive commands go here
    command
    --snip--
    ;;
 *)   # non-interactive commands go here
    command
    --snip-
    ;;
esac

13.4.2 The tcsh Shell

The standard csh on virtually all Linux systems is tcsh, an enhanced C shell that popularized features such as command-line editing and multi-mode filename and command completion. Even if you don’t use tcsh as the default new user shell (we suggest using bash), you should still provide tcsh startup files in case your users happen to come across tcsh.

You don’t have to worry about the difference between login shells and non-login shells in tcsh. Upon startup, tcsh looks for a .tcshrc file. Failing this, it looks for the csh shell’s .cshrc startup file. The reason for this order is that you can use the .tcshrc file for tcsh extensions that don’t work in csh. You should probably stick to using the traditional .cshrc instead of .tcshrc; it’s highly unlikely that anyone will ever use your startup files with csh. And if a user actually does come across csh on some other system, your .cshrc will work.

Example .cshrc

Here is sample .cshrc file:

# Command path.
setenv PATH /usr/local/bin:/usr/bin:/bin:$HOME/bin

# EDITOR and VISUAL determine the editor that programs such as less
# and mail clients invoke when asked to edit a file.
setenv EDITOR vi
setenv VISUAL vi

# PAGER is the default text file viewer for programs such as man.
setenv PAGER less

# These are some handy options for less.
setenv LESS meiX

# By default, give other users read-only access to most new files.
umask 022

# Customize the prompt.
# Substitutions include:
# %n username %m hostname %/ current directory
# %h history number %l current terminal %% %
set prompt="%m%% "