8 ms·

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 fro

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.

philsnow 4y ago
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 4y ago
  I use backtick, hen two back ticks, then four. Only rarely have to go to eight backticks. :)
- xenophonf 4y ago
  > 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 4y ago
    Embedded Linux user? We used screen & minicom extensively in my unis satellite lab
  - copperblue 4y ago
    [dead]
- em-bee 4y ago
  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 4y ago
  I can't figure out an use case for your setup, can you help a bro out?
  - Jtsummers 4y ago
    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 4y ago
    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.
    - ilyt 4y ago
      I do that except with terminal emulator sessions. One window with few tabs per virtual desktop, as I rarely need to have more than 2-3 projects open at the time it works fine. But... isn't tmux sessions exactly what you'd need for that? One session per project, then just connect to servers from within tmux windows There is even switch-tree (default C-b w) that will show each session with every sub-window in it, and even preview window below that showing each terminal (refreshable via space)
- kzrdude 4y ago
  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.
  - qwertox 4y ago
    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/ https://zellij.dev/screencasts/ [1] https://www.youtube.com/watch?v=dFkGNe4oaKk https://www.youtube.com/watch?v=dFkGNe4oaKk
  - dmd 4y ago
    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 4y ago
      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 4y ago
        Yeah, but that's more than twice as many keypresses now.
        OrderlyTiamat 4y ago
        I recommend using tmux mode and adding its keybind to locked mode, that way you get the same key interactions as tmux itself. Sadly, zellij doesn't offer the same options for which key that will be (in screen and tmux I like using C-] cause it's usually unused, but you can't use that one in zellij)
- ilyt 4y ago
  I just have one level and search function. C-b s gets me graphical(via rofi + some scripting) searchable list of windows, in rare cases where I'd need tens of them. But it took me a while to make tmux keybindings that are fast & convenient, screen defaults (aside from C-a that collides with bash/emacs) on keybindings are way better.
- Dylan16807 4y ago
  > 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. I'm missing something here. Why does tmux need to know or care?
- dbtc 4y ago
  I occasionally open tmux on a remote machine from within a local tmux. Using c-bb to get to the nested one doesn't seem that bad to me as long as it's only 2-deep. But why not just change the escape key on each machine's .tmux.conf?
echelon 4y ago
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 4y ago
  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 4y ago
    [deleted]
- kelnos 4y ago
  > ...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.
jakswa 4y ago
Looks like zellij follows the same behavior as screen, if I'm testing right. I also prefer screen/zellij's choice here.
eikenberry 4y ago
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 4y ago
  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.

philsnow 4y ago

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 4y ago
I use backtick, hen two back ticks, then four. Only rarely have to go to eight backticks. :)
xenophonf 4y ago
> 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 4y ago
  Embedded Linux user? We used screen & minicom extensively in my unis satellite lab
- copperblue 4y ago
  [dead]
em-bee 4y ago
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 4y ago
I can't figure out an use case for your setup, can you help a bro out?
- Jtsummers 4y ago
  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 4y ago
  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.
  - ilyt 4y ago
    I do that except with terminal emulator sessions. One window with few tabs per virtual desktop, as I rarely need to have more than 2-3 projects open at the time it works fine. But... isn't tmux sessions exactly what you'd need for that? One session per project, then just connect to servers from within tmux windows There is even switch-tree (default C-b w) that will show each session with every sub-window in it, and even preview window below that showing each terminal (refreshable via space)
kzrdude 4y ago
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.
- qwertox 4y ago
  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/ https://zellij.dev/screencasts/ [1] https://www.youtube.com/watch?v=dFkGNe4oaKk https://www.youtube.com/watch?v=dFkGNe4oaKk
- dmd 4y ago
  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 4y ago
    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 4y ago
      Yeah, but that's more than twice as many keypresses now.
      - OrderlyTiamat 4y ago
        I recommend using tmux mode and adding its keybind to locked mode, that way you get the same key interactions as tmux itself. Sadly, zellij doesn't offer the same options for which key that will be (in screen and tmux I like using C-] cause it's usually unused, but you can't use that one in zellij)
ilyt 4y ago
I just have one level and search function. C-b s gets me graphical(via rofi + some scripting) searchable list of windows, in rare cases where I'd need tens of them. But it took me a while to make tmux keybindings that are fast & convenient, screen defaults (aside from C-a that collides with bash/emacs) on keybindings are way better.
Dylan16807 4y ago
> 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. I'm missing something here. Why does tmux need to know or care?
dbtc 4y ago
I occasionally open tmux on a remote machine from within a local tmux. Using c-bb to get to the nested one doesn't seem that bad to me as long as it's only 2-deep. But why not just change the escape key on each machine's .tmux.conf?

echelon 4y ago

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 4y ago
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 4y ago
  [deleted]
kelnos 4y ago
> ...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.

jakswa 4y ago

Looks like zellij follows the same behavior as screen, if I'm testing right. I also prefer screen/zellij's choice here.

eikenberry 4y ago

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 4y ago
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.