Linux – Updating screen session environment variables to reflect new graphical login

dbusenvironment-variablesgnu-screenlinuxxorg

I use linux, and I like to do all my command-line work within a single screen session, so that I can restart my graphical login and such without losing my terminals. However, when I log out and back into my graphical session, this changes all my session environment variables, such as DBus sessions. This means that after logging in again, my screen session now has the old (and wrong) environment variables. So now when I try to start graphical programs from my screen session, at best they emit a warning about not being able to connect to the session bus. At worst, they fail to start completely.

So, what I'm looking for is a way to modify environment variables in a running instance of screen, so that all subsequently-created screen windows will inherit the new environment variables. Is there a way to do this?

Best Answer

You cannot start a shell script from the screen session since it would inherit the old environment. You can however us a fifo to get the new environment variables into the old screen session. You can fill that fifo when you start your graphical session.

#!/bin/bash
FIFO=/tmp/your_variables
[ -e $FIFO ] && cat $FIFO > /dev/null || mkfifo $FIFO

# save number of variables that follow
NVARS=2
echo $NVARS > $FIFO
echo ENV1=sth1 > $FIFO
echo ENV2=sth2 > $FIFO

Start that script in the background on login (it will only terminate when all variables are read from it).

Now you can read from the fifo, e.g. add this function to your .bashrc

update_session() {
  FIFO=/tmp/your_variables

  NVAR=$(cat $FIFO)
  for i in $(seq $NVAR); do
    export $(cat $FIFO)
  done
  #delete the pipe, or it will not work next time 
  rm $FIFO
}

so that you can in your old screen session

update_session

screen and Environment Variables

By default, screen passes along to its shells (and other processes) whatever environment variables it had when the session was started (i.e. reconnecting does not change which environment variables are given to new shells). But because both screen and shells' configuration files commonly change environment variables, there are many places where unexpected changes can be introduced. There are a few variables, like TERM, that screen it almost always changes, but these are generally required for the functionality that screen provides.

Let's say that neither your shell's configuration, nor screen's configuration will modify a variable named FOOBAR (fairly likely, all in all). If you start a session with FOOBAR=foo screen, then all the shells created in that session will have an environment variable named FOOBAR with a value of foo.

Things get more complicated for variables that either screen or your shell might modify.

Missing Settings When Using screen

Login Shells

If you find that some settings are missing in shells started by screen, it may be because your shell is configured only to update those settings for ‘login’ shells. Most shells understand a special convention (in C: **argv == '-') that screen can be configured to use.

Per the screen documentation:

shell command

Set the command to be used to create a new shell. This overrides the value of the environment variable $SHELL. This is useful if you'd like to run a tty-enhancer which is expecting to execute the program speci- fied in $SHELL. If the command begins with a '-' character, the shell will be started as a login-shell.

To have screen start shells as ‘login’ shells, start screen with screen -s -/bin/bash, or add this line to your .screenrc:

shell -/bin/bash

Adjust for the path to whatever shell you happen to be using.

screen Configuration

Missing or reset environment variables could also be due to setenv and unsetenv commands in a screen configuration file. You will have to check both the .screenrc in your home directory and whichever file your compilation of screen is using as the ‘system screenrc’ (you might try a command like strings "$(which screen)" | fgrep -i screenrc to find the pathname that was configured at compile time–it is usually /etc/screenrc for a system-installed screen; add-on installations will probably use some other pathname). You can use SCREENRC=/dev/null SYSSCREENRC=/dev/null screen to temporarily avoid these settings files, but there is a compile-time option that prevents the effective use of SYSSCREENRC (presumably so that system administrators can force some bit of initial configuration).

Duplicate Settings When Using screen

It is fairly common to add items to an environment variable like PATH in a shell's configuration file(s) so that the updated value is available to normal shell sessions (e.g. xterm or other terminal windows, console sessions, etc.). If such items are added in a shell's per-shell configuration (or, if you are using the -/path/to/shell setting described above, in the shells per-login configuration) then the shell started by screen will likely have multiple copies of the added items.

One strategy to avoid this is to put all additions to variables like PATH in the per-login configuration of your shell and avoid using the -/path/to/shell shell setting with screen.

Another strategy is to only conditionally add the new items to the variable. Depending on the shell, the code to do this can be a bit complicated, but it can usually be encapsulated in a shell function for easy use.

Yet another strategy is to always start with a fixed value in your configuration files. This can sometimes cause problems when moving your configuration files from system to system when the default values might vary significantly.

Diagnostics

If you can not directly spot where a particular modification is happening, you can try the following to track down where the change is happening.

Check the current value in your initial shell:

echo "$PATH"

Check how the shell itself modifies the value when a sub-shell is created:

/bin/bash -c 'echo "$PATH"'

Check how the shell modifies the value when a ‘login’ sub-shell is created:

perl -e '$s=shift;exec {$s} "-$s", @ARGV or die "unable to start shell"' /bin/bash
echo "$PATH"
exit

Check how screen modifies the value:

printf '#!/bin/sh\nl=/tmp/echo-var.log;rm -f "$l"; echo $PATH >"$l"' >/tmp/echo-var &&
chmod a+x /tmp/echo-var &&
screen -s /tmp/echo-var &&
cat /tmp/echo-var.log

Linux – How to set environment variables for a graphical login on linux

You can always put them in .profile, so they should apply for any login.

Problems occur however, if a .bash_login exists: In that case, bash won't read .profile.

If you want your variables from .profile to apply both in bash and for other logins, don't use .bash_login! Put bash specific variables in .bashrc instead.

Or alternatively, include .profile from .bash_login