Linux/Unix logon script

I wonder if you have ever encountered such a scenario. when you need to set an environment variable or run a program to set your shell or desktop environment, but I don't know where it is the most convenient location. I wonder if you have ever encountered such a scenario. when you need to set an environment variable or run a program to set your shell or desktop environment, but I don't know where it is the most convenient location.

There are some common situations, such as from the Debian package management program to the Iaas management, many tasks need to set environment variables to run normally.

Sometimes, a program usually only needs to run once upon first login, such as the xrandroid command.

In addition, some programs are occasionally injected into the shell, such as rbenv, rvn or SitePoint's own envswith program.

Let's take a look at some of the common options in Debian GNU/Linux Jessie installation and try to understand it all.

/Etc/profile

By default, Debian provides the/etc/profile file, which is used to set the $ PATH variable ($ PATH is usually used to declare the search PATH of the command) and takes effect immediately. The following code is part of/etc/profile.

if [ "`id -u"` -eq 0 ]; then    PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"else    PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"fiexport PATH

For convenience, the path of the root user (ID 0) is different from that of any other user. This is because the location of the system binary Directory (sbin directory) is traditionally a reserved location for system management programs or programs that must run as root. The games path is omitted for the root user, because it is impossible to use the root user to run the game program unless necessary.

Next, the/etc/profile processes the setting of the $ PS1 variable. The $ PS1 variable is used to set the main prompt string (that is, the character displayed when the user logs on ). Except that the system shell is Bash, the system $ PS1 variable is set to $ by default (the root user is # by default #). If the system shell uses Bash, the/etc/bash. bashrc file replaces the $ PS variable to process the main prompt string (unless otherwise specified ). Later we will briefly talk about/etc/bash. bashrc.

Therefore, we can infer that/etc/profile will be read by all shells during login (for example, using the login command. /Etc/profile calls the id command to read the user id, instead of using the more efficient Bash built-in variable $ {UID }. Bash uses the configuration of a specific source instead of defining a fancy shell prompt, because Bash supports special characters escape by backslash, such as \ u (username) and \ h (host name ), many other shells do not support this definition. /Etc/profile should be compatible with POSIX to be compatible with any shell installed by the user.

Debian GNU/linux is usually pre-installed with Dash, which is a basic shell designed only to implement POSIX (and some Berkeley) extensions. If we modify/etc/profile (backup before modification) to set different values for PS1 = '$', and then simulate a Dash logon (using the dash-l command ), we can see that Dash uses our custom prompt. However, if we call the dash command without the-l parameter, dash will not read/etc/profile. In this case, Dash uses the default value (which means that the value of PS1 is the value we modified before ).

The last interesting thing related to/etc/profile is the following code snippet:

if [ -d /etc/profile.d ]; then    for i in /etc/profile.d/*.sh; do        if [ -r $i ]; then            . $i        fi    done    unset ifi

In other words, any readable content that matches/etc/profile. d/*. sh will be treated as a variable source. This is very important because it indicates that directly editing/etc/profile is never actually needed (so you can recover your previous backup ). Any variables defined above can be configured in a separate file, and then override the settings in/etc/profile. The advantage of this is that it allows the system to automatically add the corresponding changes to the/etc/profile file during the system upgrade. Because the Apt package management system of Debian usually does not modify the default configuration file.

~ /. Bash_profile ,~ /. Bash_login, and ~ /. Profile

A potential problem with/etc/profile is that it is located in the path within the system range. This means that modification affects all users on the system. This may not be a big problem on a personal computer, but modification also requires root permissions. For these reasons, each individual Bash user account can be created ~ /. Bash_profile ,~ /. Bash_login and ~ /. Profil any of these files serves as the source of the Bash configuration file. In the listed order, the first file found will be used as the configuration file, and the rest will be ignored.

Other shells, such as Dash, support similar things, but only search ~ /. Profile file. This allows you to configure a separate. bash_profile file for specific Bash application scenarios. if you need to switch to Dash or another shell in some cases as the logon shell (for example, through the chsh-s dash command ). Yes ~ /. Profile is used as the configuration file for these shells.

Note that the default Debian framework Directory (/etc/skel, used to store the files and directories to be copied to the home directory of the new user account) contains. profile file, but does not contain. bash_profile and. bash_login file. In addition, Debian uses Bash as the default shell. Therefore, many Debian users are used to placing their Bash logon shell settings in the. profile file.

I have seen installation instructions for some projects, such as RVN. we recommend that you create a project. bash_profile file, but it is very dangerous to do so. based on the knowledge above, we know that this will change the user's shell environment. Even if the. profile file is not modified, it may use the default value ~ /. Profile function, set ~ /Bin to $ PATH environment variable. One option that may improve security is to put. bash_profile as a symbolic link file of. bash_rc in the/etc/skel directory before creating a user's account.

If we view the default. profile script of Debian Jessie, we can see the following code snippet:

# if running bashif [ -n "$BASH_VERSION" ]; then    # include .bashrc if it exists    if [ -f "$HOME/.bashrc" ]; then        . "$HOME/.bashrc"    fifi

This is similar to what we see in/etc/profile. if shell is Bash and/etc/bash is found. bashrc file,/etc/bash. the bashrc file is used as the Bash configuration file. The significance of this will be discussed in the next section.

/Etc/bash. bashrc and ~ /. Bashrc

At startup, Bash reads/etc/bash. bashrc and ~ /. Bashrc, but only when Bash Shell is used as an interactive Shell instead of logging on to Shell startup (which means it is started through xtem), it will follow this order, which is the standard behavior of Bash Shell. However, Debian ranges from/etc/profile ~ /. Get the configuration file in the profile login script. This significantly changes the behavior so that/etc/bash. bashrc and. bashrc (if they exist) are always called At Bash startup, regardless of whether the Shell is logged on or not. Do not expect this situation to be the same in different releases.

. Bashrc is a good place to add command aliases. In fact, some users have too many aliases, so they prefer to put them in a separate file. The default. bashrc of Debian searches for. bash_alias. If this file exists, it will be used as the alias configuration source. So you can save all Bash aliases in this file at will. If you want to, the. bashrc file is also an excellent place for you to override shell variables, such as $ PS1 or $ HISTSIZE. Debian's default. bashrc has more than 100 rows, but it can still be read very clearly with good comments. According to the name,. bashrc is not a source of other non-Bash shell configuration files.

~ /. Xsession and ~ /. Xsessionrc

If you are a GNU/Linux desktop user, log on to the console locally (instead of logging on to the program through getty), then/etc/profile and ~ /. Profile does not work as expected. Some display managers directly regard these files as incorrectly configured files, such as Gnome Display Manager. However, some other display managers, such as LightDm, do not. Fortunately, you have other options.

When you start an X Window System session (whether it is to use display management or start startx from a virtual terminal), the/etc/X11/Xsessionshell script will be executed. This is basically equivalent to the login shell call/etc/profile. This is only effective for X Window, and is executed directly instead of using it as the source configuration file. But it is also quite complex, similar to how/etc/profile starts from/etc/profile. how to read the configuration from/etc/X11/Xsession. read the configuration from the/etc/X11/Xsessions script in the d/directory. All script names in the/etc/X11/Xsession. d Directory start with numbers, so all scripts are read in numerical order.

Debian Jessie contains a file named 40 × 11-common_xsessionrc. the job of this file is to check ~ /. Xsessionrc is readable. If yes, it is used as the source of the configuration file. This makes ~ /. Xsessions is a perfect place to load environment variables or run a one-time application (such as xrandroid or xmodmap) (only applicable to X sessions ). If you want to, you can also set/etc/profile or ~ /. Profile as the source. Any specified environment variables will also be inherited by your Session Manager (if not yet inherited ). Note that. xsessionrc does not exist by default. you need to create this file by yourself.

If we continue to browse the files in/etc/X11/Xsession, we will find that 50 × 11-the common_determine-startup will decide which session manager to load. If ~ The/. xsessions file exists and is executable. it is saved and then executed as part of 99 × 11-common_start. When ~ /. Xsession is used to run the session manager. The X session will be canceled. When the script is terminated, you will return to the display manager logon interface.

And ~ /. Xsessionrc is similar ,~ /. Xsession does not exist by default. you can create one as needed. You may create a simple. xsession script similar to the following.

# Start our session manager of choice.#exec x-session-manager

X-session-manager is set to any content configured by the update-alternatives command by default. in this way, you can easily change the default session manager in the system, you only need to replace x-session-manager with/usr/bin/startfce4 (switch to XFCE), and other user accounts will be completely unaffected.

Of course, many display managers provide the ability to directly select a public session manager from the logon interface, so this file is usually unnecessary. However, xsession provides more flexibility. you can use any program to call this file, not just the Session Manager. For example, you can call chromium or iceweasel in a while loop, instead of performing basic kiosk mode settings.

~ /. Bash_logout

We previously introduced the files read when users run interactive Bash to log on to shell. But what if you want to run the program after logging off? For this example ,~ The/. bash_logout file is very convenient. In Debian, the default configuration is only used to clear the screen (I think it is important from a security perspective), but you can imagine that it can be used for other purposes, for example, A few seconds reminder is displayed before you leave your machine.

The main limiting factor is that. bash_logout is read only when the interactive shell is logged out, and cannot be assumed that it will be loaded when the X session is logged out.

Other options

The above general options have been introduced for you. Other options may exist, depending on your installation environment (such as/etc/environment), but I don't think they may exist on other platforms, and seldom need to contact them.

Example

So where should you place your system-range environment variables? If you want an environment variable to affect all users,/etc/profiled./someifle. sh is a good choice. However, this assumes that you are using a logon manager with/etc/profile as the configuration source. Otherwise, you can add a script (as an administrator) to/etc/X11/Xsession. d/to replace/etc/profile as the configuration source.

If you want a script to find a private directory PATH and add it to your PATH, you need to consider whether the directory will move a lot of things. the user needs to log out and then log on to change the PATH during the user session. If you add the code to. bashrc, this means that the code will be executed every time the user opens xterm. it may not be ideal if the execution takes more than half a second. This is a trade-off.

If you only want an environment variable for your personal login session, and it only cares about the X session, you can add it ~ /. Xsessionrc. The advantage of this is that it is usually used for all programs started through the X session manager, because it is set before The X Session Manager is started and inherited. For example, some graphics drivers can run

export vblank_mode=0

To disable vsync. Therefore, variables in. xsessionrc affect all programs.

However, if this line is added to. bashrc, only programs that log on through xterm will be affected. Programs started through a window manager run as usual. You can add it to. profile and use. xessionrc as the source of. profile. However, when your X service is not running, you do not need to export environment variables.

I hope you can better understand how the login and logout scripts work on the Debian GNU/Linux system.