11 ms·

Notables from 4.2.0: * layouts * window groups * better mouse support * vertical split * new and expanded commands Though I doubt this will entice m

Notables from 4.2.0: * layouts * window groups * better mouse support * vertical split * new and expanded commands Though I doubt this will entice me back from tmux, even though my primary motivator at the time (ages ago) was lack of vsplit in screen. Also notable is if you upgrade you can't re-attach to sessions started by an older version of screen.

_ak 12y ago
Exactly my thought: I switched from screen to tmux years ago, why I should care now? tmux does everything that screen didn't back then, and has improved even more since then.
- skrowl 12y ago
  In the *nix world, when something gets abandoned people are pretty quick to move on. I've been using tmux for a long time as well and see no need to even consider going back to screen.
  - pilif 12y ago
    screen supports serial lines and zmodem. While that might not be something you'd use a lot these days, it's very handy when dealing with equipment from the stone-age. Thankfully though, I can have both screen and tmux on my machine, so may day-to-day tool is tmux and screen gets used whenever I need a time machine (which still happens at times)
    - raimue 12y ago
      Couldn't you just use minicom, picocom, or some similar tool inside tmux? Is there a unique feature of screen that is not satisfied by these standalone alternatives? I am curious, as for me this setup is good enough to see debug messages on the serial console.
      - pilif 12y ago
        The reason why I prefer screen over minicom is that minicom has a lot of features related to dialling modems and accessing mailboxes, none of which is relevant to the case of setting up equipment. A quick screen /dev/ttyS0 115200 beats writing a configuration file, learning another text based stateful UI and working around various instances of your tool trying to be helpful and helping you dialling a modem. Keep in mind that this could be related to the default minicom config my distro shipped back when I was "evaluating" my options, but because screen works totally well for my cases, I've had since zero motivation to go back and give minicom another try.
        duskwuff 12y ago
        You might want to give picocom a try. Equivalent command line is: picocom -b 115200 /dev/ttyS0 It's also got a lot of serial-specific features closer to hand, like changing the baud rate, sending a break, toggling RTS/CTS, etc.
        mzs 12y ago
        Or tip or cu too.
    - vdm 12y ago
      cu (from Taylor UUCP) with lrzsz. http://wiki.soekris.info/Updating_Bios http://wiki.soekris.info/Updating_Bios
      - voltagex_ 12y ago
        I have a distinct memory of being unable to quit cu. Was I just missing the SIGHUP command?
- wting 12y ago
  I've tried switching to tmux a few times but it never stuck because my workflow involves multiple terminals attached to different windows of the same session. However this isn't allowed in tmux without some hackery / wrapper scripts.
  - sillysaurus3 12y ago
    Would you mind going into more detail about your workflow? It seems interesting, and I'd like to learn it. You use Ctrl-Alt-F1 through Ctrl-Alt-F6 to fire up multiple terminals, right? You're saying you have screen running on one of those terminals, and then from other terminals you're somehow attaching to different windows of that one screen instance? How's that done? It sounds pretty clever. What are the advantages of doing it that way?
    - ordinary 12y ago
      -x Attach to a not detached screen session. (Multi display mode).
      - sillysaurus3 12y ago
        Indeed, thanks! I really appreciate it! I was hoping to hear about their workflow, though. What are the advantages of using that? How does multi display mode fit into their workflow in practice? I could try to think of use cases myself, but I prefer to learn from the experience of others whenever possible.
    - deleted 12y ago
      [deleted]
  - easytiger 12y ago
    > I've tried switching to tmux a few times but it never stuck because my workflow involves multiple terminals attached to different windows of the same session. You are going to need to explain this as it sounds exactly to me what tmux does
ef47d35620c1 12y ago
tmux is included in OpenBSD base too. So if you use OpenBSD, it's there by default.
mhd 12y ago
That was my problem with tmux. I don't really care for vsplit (and could've had that with screen patches), so feature-wise there's no big difference. Some version of screen is often pre-installed on servers, so that's probably my first choice when it comes to situations where running things in the background is my prime motivation. For multiplexing on my home system that's not an issue, so both would be fine. I recently started trying out tmux for that purpose as someone told me its memory usage wasn't as creeping. Can't really detect a big difference, though, after a while both of them take up a few hundred megs. Not close to the vim vs. emacs holy war level. More like emacs vs. xemacs. Or did I miss some hidden gems of either of them?
- joaomsa 12y ago
  Funny you mention vim vs emacs. tmux also supports vi keybinds, big selling point over screen IMO.
  - josteink 12y ago
    > tmux also supports vi keybinds, big selling point over screen IMO. I guess this solidifies me good and well in the screen/emacs camp :)
    - chazu 12y ago
      Tmux has emacs-like bindings turned on by default, so don't be afraid. =)
    - easytiger 12y ago
      emacs & tmux get along a lot better than emacs & screen
  - djeikyb 12y ago
    I glanced at a couple screen manuals. Looks like both tmux and screen support rebinding all the commands.
- djeikyb 12y ago
  I enjoy how readable tmux conf files are. My screenrc is barely legible without the manual open in another shell. I mean, I guess it doesn't matter too much once you've got it working. But I never open my tmux.conf and ask myself wtf is going on.
ejstronge 12y ago
I too have moved to tmux, primarily because it seemed easier to create/format status bars in tmux; I already had the vertical split patch. One thing I miss from using Screen is being able to cycle through all the windows you have while maintaining a given screen layout. For example, if you had vim, tail -f logfile, and a man page visible, but you'd opened python earlier, you could: 1. Swap out the man page with python 2. Run what you needed in python, update vim, go back to the python pane and 3. Swap the python for the man page all without losing the splits you'd set up.
michaelmior 12y ago
The point about not being able to reattach to old screen sessions is a big one. Especially for those who happen to be running daemons in screen. Ill-advised, but of course it happens and can be useful sometimes for anything that isn't mission critical.
- dingaling 12y ago
  Yes, it is very naughty but I find daemon-in-[screen|tmux] to be very useful for monitoring a new daemon's output and keeping an eye on its uptime / robustness. Once we're happy with it we can dispatch it to the depths of init.
  - judk 12y ago
    You can view a process's logs with 'tail' from any terminal.
    - sp332 12y ago
      But not stdout/stderr.
      - CUViper 12y ago
        If you're on systemd, all stdout/err is sent to the journal.
- judk 12y ago
  'disown' to detach the daemon from the controlling terminal?
- prg318 12y ago
  Running a daemon in screen can also been useful when for whatever reason the daemon accepts commands via stdin. I know a lot of game servers do this. For example, with the Quake3 server you can use stdin to list users, ban users, change maps, and do other things without having to launch a game client and authenticating as a server admin. Although I guess technically if a server process supports interactive input then its not a "daemon" anymore, but I'm not keeping score.
rjzzleep 12y ago
keep in mind that while those are notables from 4.2.0 the list of changes since the last screen release is actually huge. vert splits for example was added in 2009, layouts in 2010. they really should have made a few releases in between. you might find some interesting patches to your use cases in here: http://git.savannah.gnu.org/cgit/screen.git/log/?h=screen-v4 http://git.savannah.gnu.org/cgit/screen.git/log/?h=screen-v4 given that it takes most distros a fairly long time to adopt new software I would say in a sense the screen devs kind of shot themselves in the legs in a way by not making any intermediary releases. I guess in a way that's a lesson to us all on how you shouldn't act if you want to keep your customer base.
- sikhnerd 12y ago
  This is an excellent point, and another big motivator for me to move to tmux Basically, if I'm going to be rolling out a new (patched) version of screen manually to all my servers/clients, might as well install tmux instead.
pfranz 12y ago
> Also notable is if you upgrade you can't re-attach to sessions started by an older version of screen. Last time tmux was updated someone pointed out this surprisingly obvious way to reconnect to and old server after an update: /proc/${pid_of_tmux_server}/exe attach I would imagine you could to the same for screen.
- Zancarius 12y ago
  > I would imagine you could to the same for screen. I'm not so sure. According to the Arch Linux announcement from 4.2.0, the switch screen made was from named pipes to sockets [1]. Presumably this implies they stripped out support for the former in the latest version, which would mean the announcements are valid and it's therefore impossible to reattach an old session. Although, it didn't matter to me. I usually read release announcements regularly before updating my distribution. It doesn't guarantee that I catch everything (or that I even remember to check), but it does limit the number of surprises I encounter. Completely closing off a few screen instances and restarting them wasn't a huge issue, but it was a mild annoyance. [1] https://www.archlinux.org/news/screen-420-cannot-reattach-older-instances/ https://www.archlinux.org/news/screen-420-cannot-reattach-ol...
  - ivank 12y ago
    The /proc/... command mentioned above uses the old binary to attach to the old session, though.
    - Zancarius 12y ago
      For screen? I didn't catch that since it appears the comment was referring to using a similar method for tmux. I can see how that would work, but the primary concern I was addressing was that in all likelihood, users are bound to update screen--and to their surprise find that they can't reattach. Keeping the old binary would make sense, though. Evidently that possibility was lost on me. My mistake.

_ak 12y ago

Exactly my thought: I switched from screen to tmux years ago, why I should care now? tmux does everything that screen didn't back then, and has improved even more since then.

skrowl 12y ago
In the *nix world, when something gets abandoned people are pretty quick to move on. I've been using tmux for a long time as well and see no need to even consider going back to screen.
- pilif 12y ago
  screen supports serial lines and zmodem. While that might not be something you'd use a lot these days, it's very handy when dealing with equipment from the stone-age. Thankfully though, I can have both screen and tmux on my machine, so may day-to-day tool is tmux and screen gets used whenever I need a time machine (which still happens at times)
  - raimue 12y ago
    Couldn't you just use minicom, picocom, or some similar tool inside tmux? Is there a unique feature of screen that is not satisfied by these standalone alternatives? I am curious, as for me this setup is good enough to see debug messages on the serial console.
    - pilif 12y ago
      The reason why I prefer screen over minicom is that minicom has a lot of features related to dialling modems and accessing mailboxes, none of which is relevant to the case of setting up equipment. A quick screen /dev/ttyS0 115200 beats writing a configuration file, learning another text based stateful UI and working around various instances of your tool trying to be helpful and helping you dialling a modem. Keep in mind that this could be related to the default minicom config my distro shipped back when I was "evaluating" my options, but because screen works totally well for my cases, I've had since zero motivation to go back and give minicom another try.
      - duskwuff 12y ago
        You might want to give picocom a try. Equivalent command line is: picocom -b 115200 /dev/ttyS0 It's also got a lot of serial-specific features closer to hand, like changing the baud rate, sending a break, toggling RTS/CTS, etc.
        mzs 12y ago
        Or tip or cu too.
  - vdm 12y ago
    cu (from Taylor UUCP) with lrzsz. http://wiki.soekris.info/Updating_Bios http://wiki.soekris.info/Updating_Bios
    - voltagex_ 12y ago
      I have a distinct memory of being unable to quit cu. Was I just missing the SIGHUP command?
wting 12y ago
I've tried switching to tmux a few times but it never stuck because my workflow involves multiple terminals attached to different windows of the same session. However this isn't allowed in tmux without some hackery / wrapper scripts.
- sillysaurus3 12y ago
  Would you mind going into more detail about your workflow? It seems interesting, and I'd like to learn it. You use Ctrl-Alt-F1 through Ctrl-Alt-F6 to fire up multiple terminals, right? You're saying you have screen running on one of those terminals, and then from other terminals you're somehow attaching to different windows of that one screen instance? How's that done? It sounds pretty clever. What are the advantages of doing it that way?
  - ordinary 12y ago
    -x Attach to a not detached screen session. (Multi display mode).
    - sillysaurus3 12y ago
      Indeed, thanks! I really appreciate it! I was hoping to hear about their workflow, though. What are the advantages of using that? How does multi display mode fit into their workflow in practice? I could try to think of use cases myself, but I prefer to learn from the experience of others whenever possible.
  - deleted 12y ago
    [deleted]
- easytiger 12y ago
  > I've tried switching to tmux a few times but it never stuck because my workflow involves multiple terminals attached to different windows of the same session. You are going to need to explain this as it sounds exactly to me what tmux does

ef47d35620c1 12y ago

tmux is included in OpenBSD base too. So if you use OpenBSD, it's there by default.

mhd 12y ago

That was my problem with tmux. I don't really care for vsplit (and could've had that with screen patches), so feature-wise there's no big difference. Some version of screen is often pre-installed on servers, so that's probably my first choice when it comes to situations where running things in the background is my prime motivation. For multiplexing on my home system that's not an issue, so both would be fine. I recently started trying out tmux for that purpose as someone told me its memory usage wasn't as creeping. Can't really detect a big difference, though, after a while both of them take up a few hundred megs. Not close to the vim vs. emacs holy war level. More like emacs vs. xemacs. Or did I miss some hidden gems of either of them?

joaomsa 12y ago
Funny you mention vim vs emacs. tmux also supports vi keybinds, big selling point over screen IMO.
- josteink 12y ago
  > tmux also supports vi keybinds, big selling point over screen IMO. I guess this solidifies me good and well in the screen/emacs camp :)
  - chazu 12y ago
    Tmux has emacs-like bindings turned on by default, so don't be afraid. =)
  - easytiger 12y ago
    emacs & tmux get along a lot better than emacs & screen
- djeikyb 12y ago
  I glanced at a couple screen manuals. Looks like both tmux and screen support rebinding all the commands.
djeikyb 12y ago
I enjoy how readable tmux conf files are. My screenrc is barely legible without the manual open in another shell. I mean, I guess it doesn't matter too much once you've got it working. But I never open my tmux.conf and ask myself wtf is going on.

ejstronge 12y ago

I too have moved to tmux, primarily because it seemed easier to create/format status bars in tmux; I already had the vertical split patch. One thing I miss from using Screen is being able to cycle through all the windows you have while maintaining a given screen layout. For example, if you had vim, tail -f logfile, and a man page visible, but you'd opened python earlier, you could: 1. Swap out the man page with python 2. Run what you needed in python, update vim, go back to the python pane and 3. Swap the python for the man page all without losing the splits you'd set up.

michaelmior 12y ago

The point about not being able to reattach to old screen sessions is a big one. Especially for those who happen to be running daemons in screen. Ill-advised, but of course it happens and can be useful sometimes for anything that isn't mission critical.

dingaling 12y ago
Yes, it is very naughty but I find daemon-in-[screen|tmux] to be very useful for monitoring a new daemon's output and keeping an eye on its uptime / robustness. Once we're happy with it we can dispatch it to the depths of init.
- judk 12y ago
  You can view a process's logs with 'tail' from any terminal.
  - sp332 12y ago
    But not stdout/stderr.
    - CUViper 12y ago
      If you're on systemd, all stdout/err is sent to the journal.
judk 12y ago
'disown' to detach the daemon from the controlling terminal?
prg318 12y ago
Running a daemon in screen can also been useful when for whatever reason the daemon accepts commands via stdin. I know a lot of game servers do this. For example, with the Quake3 server you can use stdin to list users, ban users, change maps, and do other things without having to launch a game client and authenticating as a server admin. Although I guess technically if a server process supports interactive input then its not a "daemon" anymore, but I'm not keeping score.

rjzzleep 12y ago

keep in mind that while those are notables from 4.2.0 the list of changes since the last screen release is actually huge. vert splits for example was added in 2009, layouts in 2010. they really should have made a few releases in between. you might find some interesting patches to your use cases in here: http://git.savannah.gnu.org/cgit/screen.git/log/?h=screen-v4 http://git.savannah.gnu.org/cgit/screen.git/log/?h=screen-v4 given that it takes most distros a fairly long time to adopt new software I would say in a sense the screen devs kind of shot themselves in the legs in a way by not making any intermediary releases. I guess in a way that's a lesson to us all on how you shouldn't act if you want to keep your customer base.

sikhnerd 12y ago
This is an excellent point, and another big motivator for me to move to tmux Basically, if I'm going to be rolling out a new (patched) version of screen manually to all my servers/clients, might as well install tmux instead.

pfranz 12y ago

> Also notable is if you upgrade you can't re-attach to sessions started by an older version of screen. Last time tmux was updated someone pointed out this surprisingly obvious way to reconnect to and old server after an update: /proc/${pid_of_tmux_server}/exe attach I would imagine you could to the same for screen.

Zancarius 12y ago
> I would imagine you could to the same for screen. I'm not so sure. According to the Arch Linux announcement from 4.2.0, the switch screen made was from named pipes to sockets [1]. Presumably this implies they stripped out support for the former in the latest version, which would mean the announcements are valid and it's therefore impossible to reattach an old session. Although, it didn't matter to me. I usually read release announcements regularly before updating my distribution. It doesn't guarantee that I catch everything (or that I even remember to check), but it does limit the number of surprises I encounter. Completely closing off a few screen instances and restarting them wasn't a huge issue, but it was a mild annoyance. [1] https://www.archlinux.org/news/screen-420-cannot-reattach-older-instances/ https://www.archlinux.org/news/screen-420-cannot-reattach-ol...
- ivank 12y ago
  The /proc/... command mentioned above uses the old binary to attach to the old session, though.
  - Zancarius 12y ago
    For screen? I didn't catch that since it appears the comment was referring to using a similar method for tmux. I can see how that would work, but the primary concern I was addressing was that in all likelihood, users are bound to update screen--and to their surprise find that they can't reattach. Keeping the old binary would make sense, though. Evidently that possibility was lost on me. My mistake.