Hacker News Reader

Comment by sikhnerd | Hacker News Reader

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.

View on HN

> 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.

> 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-ol...

The /proc/... command mentioned above uses the old binary to attach to the old session, though.

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.

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

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.

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.

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?

There's a feature that I've discovered recently that makes vertical split a lot more useful. It's PREFIX+z. it maximises the current pane. This means you can use mouse to select-copy without spanning multiple panes. Then you can do PREFIX+z to return to panes.

    > did I miss some hidden gems of either of them?

They're pretty similar. I think I moved to tmux because it was easier to get going in openbsd.

An odd advantage I've found for it - there's a great book - Pragmatic Guide to Tmux. It's very thin, yet contained all of the features I thought I wanted, and a couple of more that I didn't know about (including the z thing from above). I like books that are both thin and yet contain everything I want.

Heh. My reason from screen is the exact opposite. It's easier to be available on all servers i ever connect to... which is why i won't care for those features anytime soon.

With PREFIX+z, you have changed my life for the better. Thanks!

> Or did I miss some hidden gems of either of them?

My three favorite features of Screen are ones the Tmux devs are strongly against adding.

* Digraphs

* Serial terminal

* Nethack mode

Digraphs are mostly for portability - when ssh-ing from OSX or Windows, I don't need to learn their compose combos. Do "^a ^V | c" and there is a ¢ symbol. It would be nice if the digraph support came from a config file, so new ones could be added.

A while back I hacked up a script for doing digraphs in tmux. It's not precisely equivalent to screen's digraph support, but it does the job and (given that it's just a Python script) can be easily extended.

http://paste.pound-python.org/show/6aCbTG3lKgCWdrRygkBG/

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.

tmux uses a client-server model. This runs into issues on OSX because when the server detaches it loses context within the window manager and then launching (e.g.) MacVim from that tmux session will cause the window manager Copy-Paste to stop working (because the OS doesn't think the process has the requisite access level).

On the other hand, it makes it a lot easier for multiple people to connect to the same tmux session. In GNU screen (at least prior versions), there was an explicit check for 'uid == 0' before allowing some of the screen-sharing features (iirc). This meant that even if you chmod'd all of the sockets/ttys that needed it, screen would still refuse to operate in that mode unless the process was setuid root.

That does suck, but there is `reattach-to-user-namespace` in homebrew which keeps the tmux server from doing that

Funny you mention vim vs emacs.

tmux also supports vi keybinds, big selling point over screen IMO.

> tmux also supports vi keybinds, big selling point over screen IMO.

I guess this solidifies me good and well in the screen/emacs camp :)

Tmux has emacs-like bindings turned on by default, so don't be afraid. =)

emacs & tmux get along a lot better than emacs & screen

I glanced at a couple screen manuals. Looks like both tmux and screen support rebinding all the commands.

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.

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.

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.

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.

You can view a process's logs with 'tail' from any terminal.

But not stdout/stderr.

If you're on systemd, all stdout/err is sent to the journal.

'disown' to detach the daemon from the controlling terminal?

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.

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.

If I understand your need correctly, I believe it's solvable. Admittedly - using hacks, etc as you speculate. But in case you're interested in a solution that's bundled up - please have a look here and see if it sorts you out:

songseed.org/exhibit/20140430/tmux.launcher.sh

If you want to use the default, just do 'tmx'. If you want to have multiple windows, themselves shared between multiple terminals, use a label when you use it. e.g. 'tmx second'.

One thing you might find frustrating is that it resizes all the terminals for the screen size of the smallest. If anyone knows a fix for this, please supply.

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?

  -x   Attach to a not detached screen session. (Multi display mode).

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.

> 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

Attach to the same session from two terminals and change windows. In Tmux, the window changes in both terminals. It just works in Screen.

I seem to recall that to make it work in Tmux, you need two sessions with the windows attached to both.

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.

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)

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.

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.

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.

Or tip or cu too.

cu (from Taylor UUCP) with lrzsz. http://wiki.soekris.info/Updating_Bios

I have a distinct memory of being unable to quit cu. Was I just missing the SIGHUP command?

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

Reply on news.ycombinator.com