[HN Gopher] Be Careful Using Tmux and Environment Variables
___________________________________________________________________
Be Careful Using Tmux and Environment Variables
Author : todsacerdoti
Score : 166 points
Date : 2023-03-04 15:41 UTC (7 hours ago)
(HTM) web link (aj.codes)
(TXT) w3m dump (aj.codes)
| douglee650 wrote:
| `screen` for life, but at this point only for CLI remote
| sessions. Local terminal guis can p much do everything
| capableweb wrote:
| I think the biggest problem I encounter when trying something
| else than tmux is copy-pasting without having to use the mouse.
| How does the "local terminal guis" you suggest as alternatives
| handle that?
| Aloha wrote:
| Control-A-[ to enter copy mode, select text, control-A-] to
| paste
| kreetx wrote:
| If the terminal gui is Emacs then it handles copy-paste well
| ;)
| b3n wrote:
| But at that point you may as well use TRAMP[1] and let
| Emacs do the multiplexing for you. Yes, (e)shell works over
| TRAMP too. ;)
|
| [1] https://www.gnu.org/software/tramp/
| crabbone wrote:
| Not quite. I don't think my setup is very special, so, I
| describe it in more detail:
|
| My company provides me with the laptop, VPN connection to
| the office network, which, in turn, connects to our
| (tiny) datacenter, where actual work happens (i.e.
| compilation, CI, testing, all happen there).
|
| Sometimes I work from the office, other times from home.
|
| The datacenter has several "jump" servers having distinct
| roles, there is a server that lets you connect to our
| OpenStack cluster, another has some resources to run a
| bunch of unrelated VMs in KVM, yet another one is the
| storage for all kinds of artifacts, s.a. Linux packages,
| Linux distro images, Docker images for development and
| testing, and then there's CI cluster.
|
| So, my typical setup is like this: I have an ansi-term
| buffer per jump server. The jump servers are running my
| tmux session. So, every time I have to move my laptop to
| a different network (eg. going home from office), I
| reconnect to the jump servers and to the tmux session
| they were running so that I can pick up from where I left
| off before disconnecting from office VPN.
|
| If TRAMP could have a persistent session, maybe, I'd not
| use tmux (I don't like that I have different commands for
| managing buffer appearance and clipboard). On the other
| hand, tmux is more universally used (at least in my
| company), so that sometimes I can simply ask a colleague
| to connect to my session, if they need to investigate
| some strange situation (only a handful of people are
| using Emacs, but almost everyone would be able to use
| tmux at where I work).
| favaq wrote:
| I switched from screen to tmux because it was often impossible
| to detach a remotely attached screen (for example when your ssh
| connection dropped and you wanted to reattach to screen).
| lloeki wrote:
| Would `screen -d -R` & al not work? From `man screen`:
| -d|-D [pid.tty.host] does not start screen,
| but detaches the elsewhere running screen session. It has the
| same effect as typing "C-a d" from screen's controlling
| terminal. -D is the equivalent to the power
| detach key. If no session can be detached, this option is
| ignored. In combination with the -r/-R option more powerful
| effects can be achieved: -d -r
| Reattach a session and if necessary detach it first.
| -d -R Reattach a session and if necessary detach or even
| create it first. -d -RR Reattach a
| session and if necessary detach or create it. Use the first
| session if more than one session is available.
| -D -r Reattach a session. If necessary detach and logout
| remotely first. -D -R Attach here
| and now. In detail this means: If a session is running, then
| reattach. If necessary detach and logout remotely first. If
| it was not running create it and notify the user.
| This is the author's favorite. -D -RR
| Attach here and now. Whatever that means, just do it.
| Note: It is always a good idea to check the status of your
| sessions by means of "screen -list".
| favaq wrote:
| Believe me I tried all combinations, lowercase and
| uppercase, it would just freeze, as if it was trying to get
| my session back, but it wouldn't do anything. It happened
| often, and I would lose my sessions, so I learnt to use
| tmux, and that's what I've been using for ten years.
| lloeki wrote:
| Interesting, that's what I've been using since forever
| and a half in the exact scenario you describe.
| saurik wrote:
| Yeah... I kind of vaguely remember having an issue with
| this sort of thing 20 years ago, but I don't remember if
| I even knew about force detach at the time. I definitely
| haven't experienced a screen session I couldn't detach--
| and I use screen a LOT--in at least 10 years... probably
| 15.
| Aloha wrote:
| screen -d [optionally] pid
|
| Will detach screen from within screen.
| screen -x [optionally] pid
|
| Will reattached with simultaneous attachment.
| screen -r [optionally] pid
|
| Will detach (if needed) and reattach the session.
| quickthrower2 wrote:
| This seems similar to VSCode and it's shell sessions. You need to
| restart VSCode to pick up new environment variables rather than
| just open a new shell. But at least you have a UI in your face to
| sort of remind you. With tmux server maybe it is less obvious
| that this will happen.
| kelnos wrote:
| I don't think it's like that at all. It's pretty normal and
| expected that when you change env vars, existing shells won't
| pick them up.
|
| In tmux's case, it starts new shells with "old" env vars, where
| "old" is "whatever was present when the first tmux session was
| started".
| AnthonyGrayson wrote:
| Is this legal information?
| devsda wrote:
| May be I misunderstood the article but the tmux behavior I see is
| slightly different.
|
| The env vars from the shell where most recent attach happens are
| inherited when creating a new pane or window. This is the case
| even when multiple terminals are attached to the same session.
|
| I'm on version 3.3a for reference.
| trollied wrote:
| I don't understand. I thought this was obvious? The other way is
| counter-intuitive.
| ajorgensen wrote:
| At least to me, it seemed most intuitive to not have a global
| server environment and always copy the environment when
| starting a new session not just on server start and have the
| existing behavior when attaching to a session.
| galleywest200 wrote:
| We had this happen at my company. I had set some new memory
| settings in a JAVA_OPTS environment variable due to heap issues.
| The DBA kept a tmux server running and would periodically restart
| our app when they needed to do work on those tables it interacted
| with during maintenance windows.
|
| The heap issues kept occurring even though I triple checked the
| ENV variables. However, ps -ef showed the old values!
|
| Once I figured out he was using tmux the issue was resolved by
| closing out all sessions and starting new ones.
| surfsvammel wrote:
| To me, this behaviour makes perfect sense and fits well with my
| intuition or mental model of how things work.
|
| Thanks anyway for a good write up
| Liquid_Fire wrote:
| I would have expected that sessions are completely independent
| from each other, and don't magically inherit some (but not
| others) environment variables from when the first session was
| created. (Especially considering the first session might not
| even exist anymore!)
|
| That said, I can understand why it would work this way for
| simplicity, if all sessions are hosted inside the same process.
|
| Luckily for me, I never use more than one session at a time, so
| this doesn't affect me.
| roomey wrote:
| It helps to understand that tmux is a server, that you
| connect to with sessions.
|
| Your first spawn of tmux starts the tmux server, all your
| sessions will connect to this server
|
| But if it is only one session you are using, w
| ajm-codes wrote:
| My domain is ajm.codes and I can't tell you how jealous I am of
| the two character domain aj.codes
|
| Anyways, I'm Not a tmux user but it seems like a nice default
| behavior to have env. variables persisted
| dolni wrote:
| This is an interesting bit of behavior but the article did not
| explain what real-world circumstances make this behavior
| meaningful.
| cauthon wrote:
| 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.
| roughly wrote:
| 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.
| ajorgensen wrote:
| 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 wrote:
| 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 wrote:
| 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.
| higherhalf wrote:
| > tmux show-environment
|
| > [..]
|
| > -WINDOWIDkj
|
| Consequence of using Vim to edit blog posts? It should be,
| according to author's dotfiles :-P
|
| Or maybe using tmux, because I also press kj to determine what
| pane I'm on sometimes.
| ajorgensen wrote:
| hahah you caught me!
| anthomtb wrote:
| His solution of using `-L` to create a new named socket for each
| server does not seem cumbersome to me. I usually run `tmux
| attach-session` only once per day, so an additional argument
| would not be a major cognitive load. And I'd imagine most people
| use shell aliases for that sort of thing anyways (I probably
| should).
| rudolph9 wrote:
| This is actually what I do every time. I thought it was
| standard practice.
| jhatemyjob wrote:
| yea i always do `tmux new -s dev` to start one and `tmux
| attach -t dev` to attach
|
| correct me if im wrong but it seems like i can just do `tmux
| new -L dev` and `tmux attach -L dev` which is actually better
| than my old muscle memory. its a win-win for me
|
| edit: actually jk it doesnt work.
|
| meh who cares i always put my env vars in ~/.profile its
| weird how OP doesnt mention that at all
| [deleted]
| Jtsummers wrote:
| The -L option is for tmux so it needs to go before the
| command as `tmux -L dev new` and `tmux -L dev attach`.
| jhatemyjob wrote:
| oh. awesome! thank you kindly
|
| edit: damn, now i have to write a custom script for `tmux
| list-sessions` #!/bin/bash for
| L in $(ls /private/tmp/tmux-501); do echo $L
| tmux -L $L list-sessions done
|
| honestly at this point it isnt even worth it. i dont
| wanna have an extra script like this. ill just put my env
| vars in ~/.profile
| metafunctor wrote:
| This is something to watch out for especially if you're switching
| from screen to tmux.
|
| When you start a screen session, it will always copy the
| environment from your shell. When you start a _second_ screen
| session, it will inherit a possibly different environment.
|
| But tmux, on the other hand, spawns a tmux server when you first
| start a session. It'll copy the environment from your shell.
| However, from that point onwards, new sessions will use the
| environment from the server and will _not_ copy the environment
| from your shell.
|
| I like screen's behavior more. A frequent use case is to start a
| long-running command as a sort of ad-hoc background job. That's
| really easy with screen (just run screen and run your command, it
| will always use the parent shell's environment) but relatively
| easy to screw up with the environment when done with tmux. It
| kind of works only if you don't have a tmux server already
| running.
| jakswa wrote:
| Looks like zellij follows the same behavior as screen, if I'm
| testing right. I also prefer screen/zellij's choice here.
| eikenberry wrote:
| Environment variables get immutably set when you run the
| process, that screen would re-evaluate them when launching
| another window is bizarre. I'd expect the opposite case to be a
| problem, that when using screen you'd export environment
| variables by accident more often.
| saurik wrote:
| FWIW, as someone who uses screen, to me the opposite is
| "bizarre"? ;P I am at a shell, and I run "bash". This opens a
| new shell, but inherits both the environment and the working
| directory from my shell. Or maybe I run "ls": same thing. Now
| I run "screen bash" or "screen ls"... this should intuitively
| run the command as if I had just run the command but do so in
| a new "window". It would be absolutely ridiculous if "screen
| ls" didn't inherit the environment from the current shell.
| echelon wrote:
| The problem here is the reliance upon environment variables
| being set by parent processes. That's always felt weird to me.
|
| I think tmux's choice is actually the sane one. You create the
| server once, then there's no more question about what
| environment variables are going to be established in the
| future.
|
| When you create a new tmux window, you should know if there's
| already a server spawned.
| Beldin wrote:
| It would make sense if there were 2 commands, tmux-server for
| starting the server and tmux-client for starting the client.
| The client would then support options to connect to an
| existing server or spawn a new one.
|
| I'm a big fan of abstracting away details of little
| importance. But if I risk using an old server with stale
| values in its environment, I prefer that to be made explicit
| and not abstracted away.
| [deleted]
| isaacremuant wrote:
| I agree that it is more sane and predictable.
|
| I'm pretty happy with this behaviour and being able to tweak
| it if I need more.
| kelnos wrote:
| How is that "predictable"? The standard behavior for more
| or less everything is that, by default, when you run a
| process, it will get its environment from the parent
| process. Getting its environment from a magical hidden
| server process that a casual user may not even know about
| is the opposite of "predictable".
| joshuaissac wrote:
| If you run an SSH client process to connect to an SSH
| server, the resulting SSH session will not inherit the
| environment from the parent process of the client by
| default. Although not the same, connecting to a tmux
| server is more similar to that than starting a regular
| child shell.
| em-bee wrote:
| it's not magical or hidden. every invocation of tmux is a
| call to a running tmux server. the only exception is when
| no server is running, in which case a new one is started.
|
| i have tmux running all the time. started once when i
| connect to a server for the first time, it keeps running
| until the server is rebooted. i have tmux sessions that
| go back years.
|
| the only time the environment is causing me trouble is
| when a new ssh connection is forwarding an ssh agent,
| which doesn't get transferred into the tmux session when
| i attach. but screen would not help here either. if you
| connect to an existing screen session it has the same
| problem. we really want a way to adjust the environment
| for specific variables on attach.
| kelnos wrote:
| > _...the reliance upon environment variables being set by
| parent processes. That 's always felt weird to me._
|
| I don't really agree. When I start a program in a shell, I
| expect it to inherit the environment of that shell. That's
| just how things have always worked, modulo some special cases
| (sudo, running a new instance of the shell in login mode,
| whatever).
|
| I personally don't think that's weird, but even if I did,
| what I care most about software behavior is predictability.
| Software should do what is expected and common, and if it
| does not, it should have a very good reason, and should find
| a way to make that obvious to the user every time it does it.
|
| This is just bad UX on tmux's part.
|
| > _When you create a new tmux window, you should know if
| there 's already a server spawned._
|
| What? Why? I use screen on and off, not super often. When I
| start a screen instance, I don't always know or care if I
| have another instance running somewhere. And yes, because
| screen follows what I'd consider a more predictable model
| here, I end up with the environment variables I expect.
|
| I think whenever we attack a UX problem by saying "the user
| should know X", we've already lost. You can't assume that you
| know how the user is going to use your software, or what
| their state of mind will be when starting it. That's just
| silly.
| cauthon wrote:
| > When I start a program in a shell, I expect it to inherit
| the environment of that shell.
|
| That's exactly how tmux works. You start a server, it
| inherits the environment of the current shell. You create a
| new session in that server, it inherits the environment of
| the server.
|
| I don't understand how forcing tmux to re-load the current
| local environment for each new shell is saner behavior. One
| natural consequence would be that new panes in existing
| sessions are also created with the new env vars, which is
| obviously undesirable.
| mananaysiempre wrote:
| >> When I start a program in a shell, I expect it to
| inherit the environment of that shell.
|
| > That's exactly how tmux works. You start a server, it
| inherits the environment of the current shell. You create
| a new session in that server, it inherits the environment
| of the server.
|
| Whether that makes sense depends on if your mental model
| has starting a server and connecting to a server to
| create a new shell as distinct actions, as opposed to a
| singular action of connecting to a conceptually always-
| present persistent environment and starting a shell
| there. Admittedly tmux's interface is mostly organized
| along the former lines, but given I prefer `tmux new -A`,
| my own model seems to follow the latter.
| ghshephard wrote:
| I don't know about other people - but I spend greater than
| 99.9% of my time inside a tmux session. It _is_ my
| windowing environment. I was reading the original post and
| just kept furrowing my brows wondering "Under what
| possible scenario could any of this possibly be a problem?"
|
| It's kind of interesting reading through the threads here
| and seeing how people don't spend their time inside tmux
| all the time but instead "start an instance on demand" -
| which I've never done but I guess works for some people's
| workflow?
|
| I'm genuinely crippled trying to use a terminal without
| tmux after having used it for so long - don't have the
| faintest clue how to copy/paste/search/organize windows
| without it.
| Nullabillity wrote:
| If I'm running in a GUI terminal I can do most of those
| in there instead. I mostly end up using tmux if I need
| multiple tabs inside a ssh session.
| echelon wrote:
| I want to echo this sentiment as well. I never use bare
| terminal sessions. Not locally, and especially not
| remotely.
|
| I think the tmux sentiment in question is held by people
| new to the tool or that don't use it as a normal part of
| their workflow or day-to-day.
| crabbone wrote:
| Ha! I didn't see you response before writing mine, but,
| yeah, I had the exact same reaction!
| crabbone wrote:
| You are not using tmux for what it's designed to be used.
| It's not for running long-running processes, even though
| you might use it this way (you could also use eg. Photoshop
| to run long-running processes, after all, it has an
| embedded JavaScript interpreter with some extra
| functionality that might allow you to do that).
|
| tmux serves the same purpose as DE, except w/o the whole
| windowing system etc. It's to allow you to switch between
| multiple applications which require terminal for
| interaction.
|
| I spend close to 100% of my time at work inside tmux, and I
| never needed to answer a question "where do the process
| variables come from?" -- it's irrelevant in the same way
| how you don't ask where does Gnome get its environment
| variables from. You simply don't rely on environmental
| variables when running tmux / don't care about them.
| [deleted]
| philsnow wrote:
| I have tried on multiple occasions to migrate to tmux (because
| _gestures vaguely_ "it's the future", screen's codebase is
| ancient and can still connect directly to a serial port etc),
| but I just don't like the primitives that tmux gives you
| ((servers,) sessions, windows, panes).
|
| I use a nested setup with screen where each level of nesting
| has a different escape key, this works really well when I want
| an inner screen to be on a different machine.
| screen '-e^Zz' -S meta
|
| and then inside that one screen '-e^Oo' -S
| project1
|
| and for a session on a remote machine mosh
| some_server -- screen '-e^Oo' -S remote_session_name
|
| I haven't figured out a way to get this to work well with tmux,
| because the local tmux server doesn't know about the remote
| tmux sessions. Whereas with screen, screen doesn't need to know
| or care about that.
|
| (edit: I use shell aliases, I don't type out the '-e^Oo' etc
| every time)
| lanstin wrote:
| I use backtick, hen two back ticks, then four. Only rarely
| have to go to eight backticks. :)
| kzrdude wrote:
| I'm looking to skip tmux and migrate straight from screen to
| zellij instead, since it's also modern. I don't have many
| problems with screen, but lack of full color support (for
| vim) and wanting more terminal control codes (hyperlinks,
| text underlines, sixel, etc) speak in favour of using a more
| modern solution.
| dmd wrote:
| I want to love zellij but can't get over how it binds its
| own actions to practically every key (vs screen/tmux which
| take just one, the prefix). Do people who use it not use
| any programs that use control or alt keys?
| kzrdude wrote:
| I also trying to come to terms with this, mostly need to
| design new custom key settings.
|
| Zellij has Lock interface, default Ctrl+G, which you can
| use and in that mode it only takes that one key, but it's
| a bit different from how screen works.
| dmd wrote:
| Yeah, but that's more than twice as many keypresses now.
| qwertox wrote:
| Thanks for pointing out zellij [0]. I wasn't aware of it
| and am really glad to have read about it.
|
| It's odd. A couple of days ago I watched Tristam Oaten's No
| Boilerplate video "Oxidise Your Life" [1] and it left me
| thinking about how Rust is moving some programmers to
| rewrite tools in Rust and, while at it, adding modern
| features. It's nice to see that.
|
| [0] https://zellij.dev/screencasts/
|
| [1] https://www.youtube.com/watch?v=dFkGNe4oaKk
| quotemstr wrote:
| > screen to zellij instead
|
| FFS. Can't we, at some point, be done with wheel re-
| invention?
| tcbyrd wrote:
| Wait until you find out how many people in the 21st
| century are still iterating on the idea of the wheel
| itself. Imagine if nobody tried reinventing wheels since
| they were first introduced and you have your answer.
| xenophonf wrote:
| > _screen 's codebase is ancient and can still connect
| directly to a serial port_
|
| That particular feature is pretty important to me, and it
| would suck if it got removed. Just because a codebase is
| ancient doesn't mean it's useless.
| ijustlovemath wrote:
| Embedded Linux user? We used screen & minicom extensively
| in my unis satellite lab
| copperblue wrote:
| [dead]
| em-bee wrote:
| i do exactly that with tmux. the primary difference is that
| don't nest tmux locally, but each tmux session is on a
| different computer, so they all just need their local config
| where the escape key is specific to the computer.
|
| why does the local tmux server need to know about the remote
| tmux session?
| pbalau wrote:
| I can't figure out an use case for your setup, can you help a
| bro out?
| Jtsummers wrote:
| Nested sessions. Hypothetical: local
| computer with screen \ \ ssh/mosh to remote A,
| run screen \ \ ssh/mosh to remote B, run
| screen
|
| If each uses the same prefix (the default is C-a for
| screen, C-b for tmux) then you have to send it multiple
| times to send a command to the screen sessions on either of
| the remote systems. If you give each a unique prefix then
| you can send the prefix once and it goes directly to the
| desired screen session.
|
| Easier to give each system its own prefix that's constant
| regardless of depth, though, than trying to remember "Did I
| connect to A first or B first today?". Or, better in my
| experience, don't nest them. It's a pain however you choose
| to deal with the prefix problem.
| philsnow wrote:
| Instead of keeping N terminals open for N projects, I
| usually keep only one open and put each project in a screen
| session, then wrap them all in a "meta" session.
|
| I started using this pattern before I moved to macos, but
| now that I'm usually on a mac, it helps because I still
| haven't gotten used to macos window / desktop management.
| Managing one terminal is easier than a half dozen.
| g0xA52A2A wrote:
| It's rather surprising how nuanced tmux can be considering its
| OpenBSD roots.
| xiwenc wrote:
| The default behavior seems logical to me. At least I think it's
| normal for general use cases.
|
| I'm curious what was your case that triggered you to dig this up.
| roomey wrote:
| I agree with you. I suspect it is around understanding that
| tmux is a server, which you start and connect to.
|
| Its my daily driver, but that means when I am in bare zsh,
| without tmux, it usually doesn't "work" for me. So, I can
| understand if someone is just spinning up tmux occasionally (to
| keep some long running program from stopping) that it can be a
| bit jarring. In some senses, the simpler 'screen' might
| actually be a better fit for that.
|
| But yea, using tmux every day for years you become very
| thankful of how it operates, keeps variables isolated, you tend
| to work in one session per project (and it's great for not
| mixing them up).
|
| But yea, it wouldn't be great if you are working away on
| something, then half way through just "start a session".
|
| Tmux isn't going to do what the op is trying to do I suspect.
|
| I'm a big tmux fan, it is awesome (in case that wasn't clear)
| ajorgensen wrote:
| 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.
| [deleted]
| paulryanrogers wrote:
| 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 wrote:
| 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
| ilyt wrote:
| 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 -> 18
|
| 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 wrote:
| 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.
| gabereiser wrote:
| 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_.
| [deleted]
| kagevf wrote:
| This part at the end is something I use a lot to re-attach to a
| running session:
|
| > to re-attach to the second session you'll need to do tmux -L
| other attach -t second.
|
| I have tmux running on a machine in my closet that I ssh to from
| a couple of different laptops. I name each session, and then
| always connect to the same session when I ssh into the closet
| machine. tmux a -d -t session-name
|
| The -d makes the sessions resize to match the current scrren size
| which is useful for me because I use different screen resolutions
| on both laptops.
| Jtsummers wrote:
| -d causes the other attached clients to become detached from
| the session. tmux, like screen, limits the size of the rendered
| window to the smallest presently connected. It happens that it
| forces a resize to match your current screen size, but that's
| not its primary purpose.
| kagevf wrote:
| Ah, OK ... I couldn't get much from the man page, but I
| recalled that I needed that to get the resize - thank you for
| the explanation!
___________________________________________________________________
(page generated 2023-03-04 23:00 UTC)