storing and restoring bash env under virtualenvwrapper

_djm_ · 2014-06-21 22:50:05

Hi all,

Does anybody know a way to store bash's current environment settings (the output of 'env') in such a way that it can be used to restore the settings later on? I'm imagining storing the output of 'env' in a variable such as 'old_env', and then using it to replace the active variables. But I can't quite figure out the necessary bash commands.

For some context - I'm using virtualenvwrapper to manage a set of Python projects. Each needs a few environment variables to be set, which I do in virtualenvwrapper's 'postactivate' script. However, they then hang around after 'deactivate'ing from the virtualenv, so I'd like to unset them. A straightforward way would be to manually specify an 'unset' for each variable I set, but it seems like there should be a better way. Another constraint is that multiple users use the virtualenvs, so saving env to a file doesn't seem to be straightforward.

Thanks for any help!

Last edited by _djm_ (2014-06-22 01:16:35)

bwmcn · 2014-06-21 23:59:49

A quick way would be to create a child bash shell. This way, the environmental variables aren't part of the parent shell, but all environmental variables will be present in the child shell.

[0] bwayne@tera:~
$ echo $FOO

[0] bwayne@tera:~
$ bash
[0] bwayne@tera:~
$ export FOO=BAR
[0] bwayne@tera:~
$ env | grep FOO
FOO=BAR
[0] bwayne@tera:~
$ exit
logout
[0] bwayne@tera:~
$ echo $FOO

[0] bwayne@tera:~
$

Make sense?

Trilby · 2014-06-22 00:10:30

The issue - it seems - is not actually storing and restoring as the title lead me to believe, but restoring the absence of variables.

The former would be as simple as `var=$(env)` then later, `eval $var`. For the latter, I think bwmcn's is the best solution. Subshells can also be launched within a script more easily with parentheses (rather than having to run bash with a here-document):

echo $foo
# foo is not set here so the script would not print anything

(
  foo="hello"
  echo $foo
  # script would echo "hello"
)

echo $foo
# foo is again not set here, so nothing would be echoed

bwmcn · 2014-06-22 00:18:54

I left out a detail. The original environmental variables will return to their values in the parent shell once you log out of the child shell.

[0] bwayne@tera:~
$ export FOO=BAR             # in the parent shell
[0] bwayne@tera:~
$ bash                             # create a child
[0] bwayne@tera:~
$ export FOO=ONI             # change FOO
[0] bwayne@tera:~
$ env | grep FOO               # verify
FOO=ONI
[0] bwayne@tera:~
$ exit                              # close child, return to parent
exit
[0] bwayne@tera:~
$ env | grep FOO              # verify that original environmental variable is still in tact
FOO=BAR
[0] bwayne@tera:~
$

Hope that's clear.

_djm_ · 2014-06-22 00:59:02

Thanks for your replies.

bwmcn wrote:

A quick way would be to create a child bash shell. This way, the environmental variables aren't part of the parent shell, but all environmental variables will be present in the child shell.

That would work really well, but I'm having trouble getting it to interact with virtualenvwrapper. If I include 'bash' in the 'preactivate' script, it seems to open a child shell that doesn't have the virtualenv activated. If I include it in 'postactivate', it has problems finding virtualenvwrapper (installing it inside the virtualenv fixes this problem, but again the active shell doesn't have the virtualenv active). I will investigate more on how virtualenvwrapper and bash interact.

Trilby wrote:

The issue - it seems - is not actually storing and restoring as the title lead me to believe, but restoring the absence of variables.

Apologies if the title was mis-stated. I would like to take the environment as at time A and recreate it at time B - which would potentially involve both unsetting variables and changing the contents of set variables.

Trilby wrote:

The former would be as simple as `var=$(env)` then later, `eval $var`.

That was my initial thought, but I get lots of 'command not found' errors - presumably because some values are not in quotes when output from 'env'. That should be resolvable with some parsing.

Trilby · 2014-06-22 01:02:16

_djm_ wrote:

That would work really well, but I'm having trouble getting it to interact with virtualenvwrapper.

I have no idea what virtualenvwrapper is or how it works - but if you are writing (ba)sh commands in a script, the parenthesis syntax I mentioned should do what you want.

_djm_ · 2014-06-22 01:16:40

Trilby wrote:

_djm_ wrote:
That would work really well, but I'm having trouble getting it to interact with virtualenvwrapper.
I have no idea what virtualenvwrapper is or how it works - but if you are writing (ba)sh commands in a script, the parenthesis syntax I mentioned should do what you want.

Yes, I think virtualenvwrapper is definitely the constraint here. Your and bwmcn's approach does exactly what I'm after without virtualenvwrapper in the picture. I've updated the post title accordingly.

Arch Linux

#1 2014-06-21 22:50:05

storing and restoring bash env under virtualenvwrapper

#2 2014-06-21 23:59:49

Re: storing and restoring bash env under virtualenvwrapper

#3 2014-06-22 00:10:30

Re: storing and restoring bash env under virtualenvwrapper

#4 2014-06-22 00:18:54

Re: storing and restoring bash env under virtualenvwrapper

#5 2014-06-22 00:59:02

Re: storing and restoring bash env under virtualenvwrapper

#6 2014-06-22 01:02:16

Re: storing and restoring bash env under virtualenvwrapper

#7 2014-06-22 01:16:40

Re: storing and restoring bash env under virtualenvwrapper

Board footer