4 ms·

This is an interesting bit of behavior but the article did not explain what real-world circumstances make this behavior meaningful.

• cauthon 4y ago
  It seems like the behavior would cause problems in the following workflow: - create first session (launch server) - detach - set environmental variables - create second session But I don't understand why you would want to follow this workflow in practice. When using tmux, all my work on that machine is done within tmux sessions, and I expect them to be sandboxed relative to each other. If I want to set an variable that's relevant to a session, I do it from within the session, not outside.
• ajorgensen 4y ago
  OP here. Apologies for not providing the real world example that triggered the behavior but here's some more background: 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. Ultimately we decided to use a named tmux socket to ensure the environment variables were picked up correctly when set via the make task but you can also use `set-environment` as well if the ergonomics hit of having to use the named socket each time is too much. It's nice that tmux provides a few work arounds but I thought the original behavior was not intuitive.
  • trollied 4y ago
    Surely you'd run a script as part of your task to make sure it was all set correctly? This just seems like a bad setup.
    • bb88 4y ago
      If you thought you were reloading the dev environment database, and found out you just reloaded your production database, you would be surprised too. And you would probably wonder why after setting the dev variables, the tmux shell didn't have them. It's one of those rare gotchas that will bite someone in the ass. And it will hurt. And when it does, you'll swear like a mother f'er.
• roughly 4y ago
  From a user perspective, it can look like indeterminate or unexpected behavior - the set of environment variables available within the tmux session depends on the state of the world at the time the tmux server was started, as opposed to when the session was started. The tmux server may start when the session starts, or it may have started much earlier - as a user, unless you're aware of this behavior and paying attention, you won't know. Other posters are right that the "correct" workflow is to set all your environment variables explicitly within the session before launching whatever process you're running, but on an ad-hoc basis, I've often found myself logged into a server and thinking "this may take a long time, I should run this in a tmux session," and this kind of behavior would have (and probably has) bitten me in that case.
  • CoolCold 4y ago
    I've found for myself that it better start tmux/screen session on server up on login and don't spend time thinking on per case basis. So 95% on ssh sessions I use run tmux inside and usually the first command after ssh login is tmux attach. 5% cases are exception when no tmux/screen available or cannot copy my own tmux.conf