I really like virtualenv when working with python code and am wondering if there existed some tool which could emulate some of it when working in bash.

What I want is some cleanly reverseble way of setting environment variables by loading/unloading configurations.

I know about a lot of tools which do some magic when entering some directory, but I guess I wouldn't want to start from something like that.


not sure if it's what you're looking for but I have this on my rc files:

mklab() {
    # creates small test environments for scripting
    local d=$(mktemp -d) && cd "$d" || return 1
    clear; bash --login --noprofile --norc
    cd - && rm -r "$d"
}; export -f mklab

it puts you in a temp directory with a clean shell to make tests and removes it afterwards.

virtualenv is a bad example for bash because here you don't "install" libraries, if you're looking for a way to easily switch between bash versions you should mention that on the question.

  • Oh yes, one does "install" "libraries": for example by sourcing sh files. – Martian Jan 4 '12 at 10:55
  • nah that's just running code, it would be the same if you copy-pasted the sourced file in your terminal. It's not a library and it's not an installation, at most it would be a set of function declarations that you manually load everytime you run the shell. – Samus_ Jan 4 '12 at 16:02

A naive attempt:

to load env:

shvirtualenv() ( source "$1"; VIRTUALENV="$1" bash; )

On exit one should save variables (or not if undesirable):

shvirtualenv_exit() {
    # one could ask here whether to save the env:
    declare -x > $VIRTUALENV

trap EXIT shvirtualenv_exit


  • It does not handle inheritance well: if you want to source another env on save it will save all and further changes in parent env are not reflected.
  • Another problem is with multiple sessions (just open another terminal) - now you will end up with conflicts


  • I would love to see separate history for the env.
  • per-project bashrc

This is a really old question, I see, and the answers here are similarly out of date...

I believe the current (2015) way of doing this with virtualenv is:

In ${VIRTUAL_ENV}/bin/postactivate:

export DJANGO_SETTINGS_MODULE=app.local_settings

In ${VIRTUAL_ENV}/bin/predeactivate:



echo 'DJANGO_SETTINGS_MODULE=EOS.local_settings' >> ${VIRTUAL_ENV}/bin/postactivate
echo 'unset DJANGO_SETTINGS_MODULE' >> ${VIRTUAL_ENV}/bin/predeactivate

I like virtualenvwrapper, which offers, amongst other things:

  • workon myvenv # activate my virtualenv
  • setvirtualenvproject # from the project directory, allows:
  • cdproject
  • cdvirtualenv
  • deactivate


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.