In GNU Screen, how can I create a new window whose shell inherits the environment of the shell in the current window?
The usual Ctrl+A C doesn't seem to do this.
2
-
1screen windows don't have environments. Only commands receive an environment when they are executed.Stéphane Chazelas– Stéphane Chazelas2013-09-09 19:30:40 +00:00Commented Sep 9, 2013 at 19:30
-
@StephaneChazelas: edited post to reflect thisricab– ricab2013-09-10 08:38:20 +00:00Commented Sep 10, 2013 at 8:38
Add a comment
|
2 Answers
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.
-
1Yeah this was the only way I could conceive of doing it too. I think you could potentially do a
bash --rcfile env.shtoo.2013-09-10 11:16:49 +00:00Commented Sep 10, 2013 at 11:16 -
Thanks for the workaround, I voted for it but won't mark it as the answer because I was looking for something less hacky.ricab– ricab2013-09-10 13:37:23 +00:00Commented Sep 10, 2013 at 13:37
-
@DravSloan, this doesn't work if there are functions in your environment: you end up getting stuff like
fn="() {function body"in your env.sh. Also doesn't work if you have a variable with the character " in the value.ricab– ricab2013-09-10 14:16:43 +00:00Commented Sep 10, 2013 at 14:16 -
envshould only report environment variable settings,setwould report functions, and the sed was set to look for a word\w+tied to the beginning of the line^followed by a=, so it shouldn't of effected functions. But I understand it was very much a "quick hack", I'm not sure if you'll find a solution though :(Drav Sloan– Drav Sloan2013-09-10 15:24:02 +00:00Commented Sep 10, 2013 at 15:24 -
@DravSloan sure, thanks anyway. Regarding the functions in the environment, this is because I exported them ( you can check the behavior with
test() { echo test; } ; export -f test ; env | grep test). BTW, please tag me if you reply here, otherwise I am not alerted (your post)ricab– ricab2013-09-11 10:41:15 +00:00Commented Sep 11, 2013 at 10:41
Exported variables, as shown by env should automatically be inherited by your new screen.
However, local variables which you have defined in your shell before starting screen, but which you have not exported, will not exist in the screen session.
Depending on how you name your variables, you could use something like this in Bash to get a readable list :
(set -o posix ; set) | egrep -v '^(_.*|[A-Z0-9_]+)='
set by itself would also list tons of functions.
(set -o posix ; set) will list only variables, but there is a ton of system variables in that list.
egrep -v '^(_.*|[A-Z0-9_]+)=' filters out all variables with a name that starts with an underscore, and all those which have only uppercase letters, numbers and underscores. That should get rid of most system variables.
So the list is restricted to variables which also (or only) use lowercase letters (and underscores and numbers). Now you could copy what you want from that list before starting screen, and paste it in there.
Of course, that is only useful if you have many variables which you forgot to export, but you do remember to check them out before starting screen...
