Env Default Setting

Diverting control from default file
ls -l /etc/profile

Hopefully the file pre-exists. If it doesn't, that's not a big deal.

Handling an existing global profile

(If the file doesn't exist, you may skip these steps related to handling an existing /etc/profile file.)

If the file exists, make a backup, in case some typo overwrites the wrong file.

cpytobak /etc/profile

Copy the contents to a filename that isn't part of the standard operating system distribution.

sudo cp -i /etc/profile /etc/proforig

Make a new, custom file that will be the system-wide defaults for all users. Have it start by running any defaults that are recommended by the distributors of the operating system.

  • (The “.lcl” extension is intended to refer to this file containing “local” customizations that may be separate from the default file bundled with the “operating system”. This way, upgrades to the “operating system” are less likely to tinker with customizations made here.)
echo [ -r /etc/proforig ] \&\& . /etc/proforig| sudo -n tee -a /etc/profile.lcl

Modify the original system file to run the new, custom file:

sudo rm /etc/profile
echo . /etc/profile.lcl| sudo -n tee -a /etc/profile

Now, we can add any desired custom commands to /etc/profile.lcl. If someone installs an operating system and overwrites /etc/profile, we can move the default /etc/profile out of the way, and overwrite it with our own one-line file which gets it back to normal (like what was just demonstrated).

Commands to run

You're welcome to viewing the file named /etc/profile.lcl, if needed), create/edit the text file named /etc/profile.lcl
echo ${VISUAL}

  • If that is not set to the desired value, then customize it now. e.g.:
    export VISUAL="nano -w"

Edit the /etc/profile.lcl file

sudoedit /etc/profile.lcl

so that the file includes the following (after any pre-existing content).

(On the “public web page” version of this text, there are some HTML comments in the upcoming text block.)

Text file

[ "X${VISUAL}" = "X" ] && export VISUAL="nano -w"
[ "X${EDITOR}" = "X" ] && export EDITOR=$VISUAL
# Hyphen by the end of the next line helps nano, breaks vi.  less ignores it.
[ "X${PAGER}" = "X" ] && export PAGER="less -R"
[ "${MANPAGER}" ] ||export MANPAGER=$( [ -x "$( which most 2>> /dev/null )" ] \
 && echo most||echo "less -R" )
[ X"${PS1}"X = X\$" "X ] && export PS1=""
[ X"${PS1}"X = X\#" "X ] && export PS1=""
[ "X${PS1}" = "X" ] && export PS1=\{\\!\}\\u@\\l:\\h:\\w/\\$" "
[ "X${HISTFILE}" = "X" ] && export HISTFILE=$HOME/.sh_history

export MANCOLORS=' LESS_TERMCAP_mb=$(printf \\e\[1\;31m ) \
LESS_TERMCAP_me=$(printf \\e\[0m ) \
LESS_TERMCAP_md=$(printf \\e\[1\;31m ) LESS_TERMCAP_se=$(printf \\e\[0m ) \
LESS_TERMCAP_us=$(printf \\e\[1\;32m ) LESS_TERMCAP_ue=$(printf \\e\[0m ) \
LESS_TERMCAP_so=$(printf \\e\[1\;44\;33m ) '

alias mancolor="env ${MANCOLORS} man"
alias man=mancolor
alias less="less -R"

[ "X${MAIL}" = "X" ] && export MAIL=/var/mail/$(id -nu)
[ "X${MAILCHECK}" = "X" ] && export MAILCHECK=15

Note: You might be interested in putting some more commands there. Go ahead. Just keep the following in mind:

  • Some of those lines are long enough that nano's word wrapping could cause issues. (nano usage indicates that Meta-L will flip wrapping. “Long line wrapping disabled” is the desired message to see.)
  • This is meant to be a system-wide file that affects all users who log in, regardless of their primary shell. Individual users can also place commands in ~/.profile for a similar effect that can be customized for each user.
  • Some programs like to have a “clean” login shell experience. If you wish to accomodate such programs, the recommended process is to have every command be silent. To do this, do not even allow output of a blank line or any other single character, as that may disrupt programs that are assuming total silence. (This is discussed more at: Hushed/Clean logins.)

    [#noisylgi]: noisier logins

    However, there is also the long-held traditions that many systems also output /etc/motd and run fortune. Both of those tasks clearly violate the “clean”/hushed login principle. This guide isn't trying to tell you wish way to act, but is simply trying to make you aware of the idea. (This guide leaves it up to you to decide whether there are reasons to keep the login hushed, or reasons to make the login noisier. Of course, if there are additional guidelines to follow, like instructions as part of a formal class, then that may have an impact on such a decision.)

    • The fortune command has been installed on a lot of Unix systems. If you're wishing for the computer to encourage people to spend a bit of time having fun (while in a text-mode environment), and don't mind violating the “clean”/hushed login principle, then you may be able to add some other software to the list. The following is meant for OpenBSD systems:
      for x in snake tetris hack robots atc sail ; do echo $x scores: ; $x -s ; done
      cfscores -a

      These commands print scores, which may encourage players to jump into the fray. This is probably not a good idea for a standardized template that gets run on multiple systems, because it will probably be better to have the competition centralized on a single system (instead of continually needing to try to compare scores on multiple systems).

      Related reading material: OpenBSD man page for “intro”, from section 6 (games), OpenBSD man page for cfscores (which is related to the canfield Solitaire card game), OpenBSD man page for rain

Here are a few other comments about some of specific lines from the example text file that was shown (just a bit earlier than this sentence).

Code related to man

Of that, the value for MANPAGER looks ridiculously complicated. In fact, that command spans more than 80 columns, so it covers multiple lines. (The character after the backslash is expected to be the “newline” character, and not any other “white space” character. In other words, the backslash is expected to be the last character on the line.) The value shown in that example was designed to work on systems that have the most command, while causing other computers to use the the less command. This documentation strived to create a single thing to type that would work well on all these systems. If you know exactly what pager you wish to use for the man command, you can simplify that line.

If you wish to adjust the aliases that are related to the man command, the colors are ANSI escape sequences. ArchLinux documentation on colors for text terminals lists values. That documentation also notes that values can be stored in the environment, and then you can refer to the strings by a name (like “txtblu”) instead of trying to remember/type the fancy ANSI escape sequence. (That might also make updates easier.) It does seem like manual s ection names, commands, and switches (including any symbols) are all using LESS_TERMCAP_md, while customizable values are all LESS_TERMCAP_us. (It would be nicer if some of these meanings could have different colors from each other, but that does not seem to be the case, based on the documentation that is currently available.)

On using the environment

The approach shown here is to set a variable, and then set an alias to use that variable. Some people might wonder, why not just put all of this into an alias? That would make a complicated alias, instead of a simple alias combined with a complicated MANCOLORS environment variable which seems... unnecessary.

Using the MANCOLORS environment variable was found to be unnecessary in OpenBSD (with the default /bin/ksh executable), and an earlier version of this documentation tried that approach. However, that approach did not work as well with some other shells on other platforms. This approach did. (As memory gets hazy about minor details, it is not currently clear what the other platforms were. Probably either Solaris (approx version 10), RedHat (version 6 or 7), or CentOS.) That is why this approach, as shown, is what this guide recommends.

Using nano as a pager

This is not really recommended. If anybody wants further details, see: using nano as a PAGER.


The reason to use -R for less is so that colors are preserved, instead of being filtered out. Depending on your operating system, you may want to add another line, such as:

alias ls="ls --color=always"

However, you should first determine if that would even be useful. In OpenBSD, such an option is not supported, and so this would effectively end up just breaking ls. For more details on trying to see colors in directory listings, see: directory listings (ls) in color (in Unix) and/or custom ls.

-R indicates escape sequences that don't move the character position, such as color changes, while -r does not have the same meaning about whether the cursor moves (as documented at Greenwood Software less FAQ about -R).

Sourcing needed

When testing, make sure to source the file, rather than executing it. If you try to execute the file, variable changes may occur in a sub-shell, and not affect the current shell. To avoid that problem, don't run the file, like this:


Instead, source the file. This is typically done with a command called period. So, instead, you should be running something like this:

. /etc/profile
Other files

Note that the /etc/profile file is the filename that is supported by the largest number of shells. However, some shells may allow specific files to override the more generic ones. If the file doesn't seem to be automatically executing, make sure you can manually execute it. If you can, your shell's documentation to see if a different file is used instead.

It is common for users to have their own profile files. Quite a few GPL-based operating systems may use the Bourne Again Shell (bash). This shell may execute a ~/.profile file if that file exists. However, the shell may simply not do that if it finds another file that it gives priority to, such as ~/.bash_profile (or perhaps also a ~/.bash_login file?). So do not trust that a specific “profile” script (login script) will be executed every time, even if it does execute once during testing. The specific details, regarding what file(s) get executed, could vary based on what shell a person uses. If this is a concern, keep that in mind when installing different shells that users may use.

Getting all processes

The most thorough way to test this would be to log in again. However, you may be able to get by, simply by running the /etc/profile script. Note that new login procedures won't affect any current processes, including other command prompts (including prompts that may be hidden within a “terminal multiplexer” program, like tmux or screen. Experience indicates that it can be somewhat easy to miss a process through manual efforts that are less disruptive than a reboot. If you're confident, you may wish to avoid the reboot by simply running /etc/profile anytime that a prompt doesn't look sufficiently descriptive.

Side note: some of this came from: setupos and makeavm.