13.3 Shell Startup File Elements
What goes into a shell startup file? Some things might seem obvious, such as the command path and a prompt setting. But 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?
This section discusses the essentials of a shell startup file—from the command path, prompt, and aliases through the permissions mask.
13.3.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 interest to a regular user. At the very least, the path should contain these components, in order:
/usr/local/bin
/usr/bin
/bin
This order ensures that you can override standard default programs with site-specific variants located in /usr/local.
Most Linux distributions install executables for nearly all packaged user software in /usr/bin. Some are occasional differences that have crept in over the years, 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 just listed. If not, your system is probably getting out of control. Don’t change the default path in your user environment to accommodate every new software installation directory. A cheap way to accommodate separate installation directories is to use symbolic links in /usr/local/bin.
Many users create 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
A newer convention is to place binaries in $HOME/.local/bin.
If you’re interested in systems utilities (such as sysctl, fdisk, and lsmod), add the sbin directories to your path:
/usr/local/sbin
/usr/sbin
/sbin
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. As just one example of what might happen, an attacker could put a Trojan horse named
lsin an archive distributed on the internet. Even if the dot is placed at the end of the path, you’d still be vulnerable to an attacker anticipating typos such asslorks. - 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. Even many shell default prompts are cluttered or otherwise mostly useless. For example, the default bash prompt contains the shell name and version number. 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:
{ } = & < >
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 (> redirects output to a file).
This simple prompt setting for bash ends with the customary $ (the traditional csh prompt ends with %):
PS1='\u\$ '
The \u is an expression that the shell evaluates to the current username (see the PROMPTING section of the bash(1) manual page). Other popular expressions include:
\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 by using \W instead.
\$ $ if running as a user account; # if root.
13.3.4 Aliases
Among the stickier points of contemporary user environments is the role of aliases, a shell feature that substitutes one string for another before executing a command. Aliases can be efficient shortcuts that save some typing. However, they have several drawbacks:
- It can be tricky to manipulate arguments.
- They are confusing; a shell’s built-in
whichcommand 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 aren’t passed onto child shells.
One classic mistake when defining an alias is to add extra arguments to an existing command—for example, aliasing ls to ls -F. At best, this can make it difficult to remove the -F argument when you don’t want it. At worst, it can have severe consequences for the user who does not understand that they’re not using the default arguments.
Given these disadvantages, you should probably avoid aliases whenever possible; it’s easier to write a shell function or an entirely new shell script. A computer can start and execute shells so quickly that the difference between an alias and an entirely new command should be unnoticeable.
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. (But you can instead 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. Include the umask command in one of your startup files to make certain that any program you run creates files with your desired permissions. There are two reasonable choices:
077 This mask is the most restrictive permissions mask; 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, this mask p. 340 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 a good choice on a single-user system because many daemons that run as pseudo-users won’t be able to see files and directories created with the more restrictive 077 umask.
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.