I 100% agree with Andrew on this. Being able to use a terminal multiplexer
like this is a *very* handy skill to have in your back pocket. I've been
using GNU Screen for ~10 years now, and am happy with it. I've used tmux
and it seems to work well, but my old fingers are stuck in their ways,
knowing the Screen shortcuts much better, so until I need a feature that
screen isn't providing, I'll likely just keep using that.

Andrew's advice is sound, though: if you're just learning one now, start
with tmux.

I do use screen for multiplexing, that's a given. Here's a quick list of
*other* things I use screen for, which are just as valuable to me as
multiplexing is:

- disconnect-resilient shells (if you're running in screen and your network
connection dies, everything keeps running)
- terminal sharing (co-troubleshooting with a co-worker, training other
devs, etc.)
- monitoring long-running processes (much easier than the nohup dance, and
easier to jump into and out of)
- serial terminal for network equipment management

(tmux can handle all of these things as well)

-Erik






On Mon, Jan 6, 2014 at 1:40 PM, Mike Miller <mbmiller+l at gmail.com> wrote:

> Thanks, Andrew.  Now I want that book!
>
> Mike
>
>
>
> On Mon, 6 Jan 2014, Andrew Berg wrote:
>
>  On 2014.01.06 10:39, Mike Miller wrote:
>>
>>  Does either of those keep the command histories for multiple login
>>> sessions stored in separate files?  My guess is "no," but that it still
>>> would help when a connection is lost.  I have been wanting for years to
>>> learn to use GNU Screen but I haven't gotten around to it.  Is there a good
>>> tutorial?
>>>
>>> If I weren't doing what I am doing, and the server crashed, I would lose
>>> all command histories.  This way I lose nothing.  I don't think screen
>>> would help unless it is continually storing its state and command history
>>> in a file.
>>>
>>
>> tmux is far more convenient than what you're doing. Its main purpose is
>> to keep several terminals open and available to you at the same time and to
>> attach and detach at will without any adverse consequences. tmux won't
>> separate your command histories across sessions (it will have separate
>> histories in each pseudoterminal), but such a thing would have to be
>> handled by your shell anyway since that is what is keeping history. Since
>> you already have shell code written to do this, it should work with some
>> minor changes.
>>
>> Also, don't use screen. It's old and buggier and has fewer features than
>> tmux. Some people still use it because they've using it for years and it
>> serves their needs, but you have no investment in it, so it will give you
>> no advantage over tmux. There are plenty of tutorials out there to get you
>> started with tmux, and there's even a book on it:
>> http://pragprog.com/book/bhtmux/tmux (it has a focus on development, but
>> I've read some of it, and the basic and intermediate stuff is very well
>> covered).
>>
> _______________________________________________
> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota
> tclug-list at mn-linux.org
> http://mailman.mn-linux.org/mailman/listinfo/tclug-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20140106/41116a51/attachment.html>