Before sendenv, but with magicwormhole (which it's built on top of):

    machine1 $ export var1=hello
    machine1 $ export -p var1 | wormhole send --text -
      On the other computer, please run wormhole receive 1-word-word

    machine2 $ eval "$(wormhole receive 1-word-word)"
    machine2 $ echo $var1
    hello

    machine1 $ export var1=hello
    machine1 $ sendenv create-vault v
    machine1 $ sendenv add-var v
    machine1 $ sendenv send-vault v

    machine2 $ sendenv receive-vault
      Please logout and login again for the changes to take effect
    machine2 $ echo $var1 # doesn't work, needed to re-login

It also, just like the eval in the first example, has the downside of requiring you to completely trust the sender since they can send arbitrary code to execute that'll get written to your shell's rc file.

Basically, if you need to share ad-hoc env vars in a single terminal session, the wormhole snippet I posted above is fine.

If you want them to persist, probably use direnv to share them, ideally tracked in version control.

If you want them to persist system-wide, use ansible or some other configuration management.

The middle-ground, of wanting them to persist so much you write them to the shell rc, but not wanting them to be version controlled or configuration managed, seems like the worst of both worlds.

Related tool: a friend and I created `diffenv` for developers to easily compare (diff) development environments including environment variables:

https://github.com/error-central/diffenv

Helps for debugging those times when you say, “well it runs fine on my machine, what’s different about your machine??”

Not sure I’d use this. Might be fun to develop, but what’s wrong with a text file you copy to your bashrc or whatever?

Ansible vault, anyone?

Cool idea!