> 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'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.
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:
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.
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.
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.
> 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.
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.
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
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.
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.
> 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
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?
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.
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.
Been using Screen for more than 10 years and it has been stable like a mountain! The only new feature that I care about slightly is the vertical split (frickin wide screens!)
C-a <TAB> is bound to the "focus" command. "focus" can receive parameters ("up", "down", "top" and "bottom") Without parameters, it defaults to "down", which is why you cycle downwards with you press C-a <TAB>.
To tab backwards, you call "focus up". It's not bound by default, but you can bind to, say, C-a U:
I'd really like to see GUI integration with screen. I'd like my X terminal application to be able to attach to a GNU screen session, display all my screen windows as tabs, and then later detach again.
Every linux/unix terminals I've tried have been woefully inadequate compared to iterm2 and its enormous feature set. It seems a little embarrassing that the linux world is outdone by the OS X world when it comes to terminals.
and codebase and dependencies, probably. i like that st is < 1000 lines of C.
> It seems a little embarrassing that the linux world is outdone by the OS X world when it comes to terminals.
yeah, there's something to this. i don't think it's just terminals, but they're a good example:
* xterm is the old standard. it's accumulated a lot of cruft because it hearkens back to the days when terminals were separate pieces of hardware.
* urxvt is a new standard: C++ and still a largish codebase, but handles mutt and mc and so on without hiccuping. also, it's scriptable in perl. does iterm2 have an embedded scripting language?
* gnome-terminal (and probably similar from KDE) aren't as large but have a bunch of dependencies and are part of larger projects
so i think it's in part due to fragmented development effort together with the fact that the unix terminal ecosystem carries a lot of dead weight back in the day of there being dozens of hardware terminal vendors that the software had to take into account ... and still does, despite the fact that emulating VT100 is all a software terminal has to take into account these days.
I'd love to expand this concept and do full window manager integration with tmux/screen, actually.
I can't see any problems with having a bottom-tabbed UI with nice tmux keybindings - "C-a 0" to go over to Chrome, quick split of current X view with "C-a %', etc would be phenomenal.
Does anyone know if this exists in some form already?
Thanks for introducing me to Xpra! I feel this is a tool that will need some getting used to.
Where does it stand in multi-user scheme of work? Suppose I need to give several users access to a certain application running on a remote server. Do I create separate user accounts for each user on that remote server? Do they start a separate display for each user? Where should I ask my noobish questions?
I'm no expert, but each user can create an xpra session, which they can connect to remotely by ssh. You just need to install it and provide ssh access. I don't know whether other options might work.
x2go might be an alternative, where you connect to get a complete desktop.
I use xpra (to the extent that it works for me, anyway). But there are situations when I don't want to attach an X app - I just want to connect to a screen in an existing terminal. Raw text over ssh is the fastest and most responsive over a laggy connection, too.
Neat changes, but I'm still going to stick with tmux. Tmux not only works better, it's changed the way I develop. Everything is done in a Tmux window with Vim and shell. Tmux is how you can create a shell-based IDE with splits and different functionality. I came from Emacs, and liked the IDE-ness of it, but I can capture almost all of that behavior with tmux + vim.
Yeah. They took ideas from things like PS1 setting with Bourne shell, and kept going. Keeping the variables to single letters was intended to have the format string be approximately the same length as it might actually be displayed. However, that doesn't work well in practice. It would be better to go with keywords (or maybe even key-phrases) instead.
I still use Screen every day. I tried to switch to tmux, but tmux's copy mode isn't as good as screen's. For example, in tmux you can't search case insensitive in copy mode, which is really a must for me. I think that's probably the biggest reason I didn't switch.
Am I the only one who extensively uses the copy mode?
CUI is either "Character User Interface", "Console User Interface", or "Captive User Interface". The first two are mostly orthogonal to "Command Line Interface" (CLI), which can be character based or graphical. The last asserts that the interface fails to play well with the shell, which is nearly always true of GUIs and is frequently true of console programs that make heavy use of ncurses (though not always, and can be true without that).
Also notable is if you upgrade you can't re-attach to sessions started by an older version of screen.