If you've set environment variables on one screen (say running bash), and then open a new screen, it is a separate bash process and therefore will not pick up the environment on the separate already running bash shell. A quick fix to get around the issue would be:
env TERMCAP= env | sed -r 's/^(\w+)=(.*)$/\1="\2"/' > env.sh
then once you've Ctrlac to get a new shell you can then
source env.sh
It's hacky and I use env TERMCAP= env
because the TERMCAP environment variable is multi-line and makes the sed
far more complicated. It's not pretty, but it works :)
You may want to change it to do:
env TERMCAP= env | sed -r 's/^(\w+)=(.*)$/export \1="\2"/' > env.sh
So the variables are also exported.
The environment is a list of strings of the form var=value
(by convention) that is passed as the 3rd argument to the execve() system call.
That list is put somewhere on the stack of the process when it starts to execute the new command just like for the list of arguments (another list of strings passed as the second argument to execve()
).
In programs using the libc (most), an initialisation code called before the main()
function is invoked, makes those environment strings available as the environ
array.
The libc
also provides with putenv
and setenv
functions that can modify (a copy of) that list that the program received. That maintained, modified copy will then be passed to the next command executed by the process or any of its children via the execvp()
/execl()
/system()
/popen()
... functions of the libc (which themselves end up calling the execve()
system call).
Now while when you build up a list of strings that you pass manually to the execve()
system call, you may pass strings like foo
(without a =
character) or =bar
(with an empty variable name), setenv
won't let you do that (setenv("", "bar", 1)
is rejected).
setenv("a=b", "c")
will also be rejected. So the strings that will be defined by setenv
will always be of the format x=y
where x
may not be empty.
That's about the only restriction (also applied by putenv
). Well those being NUL terminated strings, of course the NUL character cannot appear in the variable name or value.
setenv("*", "x", 1)
, or setenv("\n\n", "", 1)
are all OK as far as setenv()
or the kernel are concerned. Now, whether you're going to be able to do anything useful with those is another matter.
Best Answer
A process inherits the environment variables from the parent, this means the first time you call
screen
(create a new one) it has a copy of all the environment variables of the parent process. Nowscreen
adjusts/creates some variables likeCOLUMNS
,LINES
,TERM
,TERMCAP
,WINDOW
andSTY
. You can also adjust or delete environment variables in yourscreenrc
withsetenv
/unsetenv
.On some systems,
screen
is setuid or setgid in order to updateutmp
andwtmp
; then a few more variables are removed from the environment whenscreen
starts, such asLD_LIBRARY_PATH
.If you attach to an existing
screen
session your environment variables won't be copied as thescreen
process already exists and has it own environment variables (from the time when you started the process before). This means your changed environment variables won't be visible in the processes started by screen as they are copied from the parent process which has the old environment variables.