If your workflow doesn't include tmux or screen, then I feel like your problem's already been answered. If you really wanted to, you could just add a "/bin/screen -DR; exit" to your remote .bashrc and the screen integration would be completely invisible after the initial instantiation.
As far as mosh is concerned, it feels like it's an extremely overengineered solution to the "I wish I had started this process in a screen session" problem, except you need to be thinking even further ahead than you would normally (installing and connecting via a mosh service, as opposed to remembering to connect to a screen session that can be run with very little prior setup and no client modification).
While the situation you describe is one that some people end up using it for - it's not the real reason mosh is useful.
Where mosh really shines is when your IP is changing too frequently (a mobile problem when you are on the move) and when you are dealing with high latency connections.
When you have to ssh in somewhere over a shitty, barely working mobile data connection - mosh is a lifesaver. It makes an otherwise unusable situation comfortable and productive.
Sure, it's handy for jumping between connections, on/off wifi and so on - but that's easy to achieve many other ways with tools that have been around for a decade or two at this point.
> solution to the "I wish I had started this process in a screen session"
Not necessarily. When I'm thethering my phone's data connection to my laptop I use mosh to ssh into my server because it resists way better to bad connectivity. No matter if I used screen or not, I would still have to kill the ssh process and connect again and reopen screen if I didn't use mosh.
I have been using Screen for years. Will Screen attempt to reconnect to a remote SSH session? I think what `screen -DR` will do is - it will automatically connect me to a screen session `after` I login to the remote machine.
But if I lost connectivity - my SSH session won't be auto-resumed from local machine in first place, I think thats one of the things `mosh` solves.
It promises lower latency etc, but I am just perhaps too slow to notice such things (or both SSH/Mosh feel equally laggy if remote connection is slow enough).
>But if I lost connectivity - my SSH session won't be auto-resumed from local machine in first place, I think thats one of the things `mosh` solves.
While true, it just seems (to me) that if that's the only problem you're solving (which is to say, not needing to type the command "ssh host" and let your key log you in) and it's at the expense of not being able to properly ForwardAgent (which I require very heavily in my line of work), then it's a lot of work for negative return.
But, again, to each their own. As mentioned below, if your latency over a phone connection is so bad that this helps you, then by all means, use it. :) I'm just noting that for pretty much everyone I work with, this would be a step backwards.
> you could just add a "/bin/screen -DR; exit" to your
> remote .bashrc and the screen integration would be
> completely invisible after the initial instantiation.
The problem is making all of those initial instantiations every time my connection is interrupted.
Huh. I certainly don't remember step 4 from my time of using screen. Is it a new feature or an option I didn't know about or something?
And what happens if I want to have two terminal tabs on my end logged into the same remote machine? (Which is basically 100% of the time for me.) It seems like that would be a case where mosh would be much smoother...
(Disclaimer: Once upon a time I used screen, but I stopped ages ago. mosh is intriguing, but as long as I'm working from home just plain vanilla ssh is all I really need...)
The ability to detach and re-attach to screen has been there since day one... that's probably one of the largest reasons most people use it. Terminal software these days can handle multiple sessions just fine - the benefit is being able to detach and re-attach.
Multiple terminals in one session was more critical back when we were using dumb terminals and whatnot - where you couldn't multiplex locally.
Just so it's clear, I meant specifically the '.bashrc runs "screen -DR"' part, ie automatically going back into the screen rather than needing to explicitly run screen -DR like I used to. (I don't seem to be able to edit my original comment at the moment.)
That's not something screen-specific. You can put whatever you want into .bashrc and it will be automatically run each time you open a new shell. pseudonym just suggested you could use it to automatically run a screen command.
> what happens if I want to have two terminal tabs on my end logged into the same remote machine
Don't do that. Open a new window in your screen instead.
Then start giving windows descriptive names. Then start giving them automatic names. Marvel at most fast you've gotten using the window selector (with type-ahead-find).
> And what happens if I want to have two terminal tabs on my end logged into the same remote machine? (Which is basically 100% of the time for me.) It seems like that would be a case where mosh would be much smoother...
You can use 'screen -x' to attach multiple times to the same session.
"I wish I had started this process in a screen session" problem
Why is everyone here assuming all programs can be run in a screen session? I run emacs over X11 through a tunnel. This is far superior to emacs in a screen session.
I've solved this by buying FastX from StarNet. I run a server on Linux and display my X programs on my desktop at work. When I get home, where I run the client on my home desktop, I can connect to the same server and disconnect my work clients and reconnect them to my home machine. It's the perfect solution for me.
As far as mosh is concerned, it feels like it's an extremely overengineered solution to the "I wish I had started this process in a screen session" problem, except you need to be thinking even further ahead than you would normally (installing and connecting via a mosh service, as opposed to remembering to connect to a screen session that can be run with very little prior setup and no client modification).