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
After sendenv:
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
sendenv also writes to "~/.bash_profile", "~/.zshrc", which is fraught (i.e. on my system they're read-only files).
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.
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.