[ajorgensen]

OP here. We have some make tasks that set up a local dev environment and rely on environment variables to control a few things. We ran into an issue where if someone started another tmux session and then ran the make task to start the dev environment the env vars wouldn't be set correctly causing some confusing behavior.

[ilyt]

I wouldn't rely on env variables. I'd make a script that goes somewhat like

    script envname command

then just loads .env.envname before executing.

For k8s work I just put some relevant variables in PS1 so it is always visible "where I am", with prompt looking like this for say "dev" env:

    [08:15:57] ^ [~] 
    k8s:dev -> ᛯ 

As for tmux behaviour, it's honestly entirely understandable. tmux have no way of knowing the intent of the user; some people might want "clean" session with defaults of what server is running, other might want some env variables copied.

I don't have that problem because I just have session being created in my WM autostart, and I just use that one session 99.99% of the time. And creating new ones usually is from tmux, not from some random shell window elsewhere

[ajorgensen]

Yeah that makes sense. To me it felt unintuitive that environment was global and only copied on server start, with a few exceptions, and not session start but that was likely just a failure in my mental model of how tmux worked.

[ilyt]

I think it's about the stuff that needs to be shared. Like variables for X11 or ssh agent.

If you start server off your graphic session then any new tmux session will get those variables and your ssh agent or graphical app will "just work".

Reading from current one by default might fuck something up if you say have some automation that starts stuff in tmux

There isn't really good way to handle it by default that would make everyone happy, screen had similar "problems".

I just have

    tmux new-session -d -s main

in my .Xsessionrc so the main session gets both SSH_AGENT stuff (I use gnupg as agent, for smartcard support) and proper DISPLAY, then just use alias to use that main session

[gabereiser]

Could you encapsulate the config to a file within your build step and set the env vars from that? Like a “remember to source <envfile> before make dev” or better, if the env isn’t set in make properly (flag), have make source it.

Environment vars are great with defaults for configuring codebases. They are designed for runtime. Build time flags can read the current environment but if your build pipeline requires custom variables you need a “dictionary” of sensible defaults that will spin up a local environment so that onboarding is as easy as git clone && make dev.

[paulryanrogers]

I wonder if it's because of export. If one puts an env var into a command alone then it should be OK. For example, `MY_VAR=1 my-commmand.sh` should leave env vars unchanged for everything else.

[ajorgensen]

Yes that should work. In our case we have a few different windows/panes that all want the same environment so it made sense to reach for export as a way to ensure the environment was set but then ran into this quirk of tmux

[BeefWellington]

You can use the include syntax for Makefiles in order to include your environment variables.

Alternately, set those vars in your shell RC and it'll work too when the shell is spawned.

IME it's stabler to kick off automation or build processes from a clean slate anyways, clearing the environment and setting specific values as required from a file.