Mosh: Scrollback and alternate screen (was: Use alternate screen on smcup/rmcup )

Or perhaps the client should always put the real terminal in alternate screen mode, for much the same reason that curses applications do—the scrollback history it generates in the primary screen isn’t particularly useful anyway.

In normal use (like line-by-line typing at the shell), the real-terminal scrollback will be somewhat useful. I'm not sure I want to give that up completely, although maybe the user would be annoyed that larger prints are only there partially in the scrollback.

Hi, I would like to know if you have any plan on this issue? I think mosh should work just like ssh, that it will enter smcup mode when the remote application requests so. I find it quite annoying when I use vim to open a large file and it leaves a lot of scrollbacks.

Here is the current proposed solution:

(a) mosh-client puts the terminal in the alternate screen for the whole time

(b) mosh-server interprets SMCUP/RMCUP the way xterm does, so people's "vim" continues to work the same as in xterm (or in screen with altscreen enabled)

(c) we grab control-pgUp and control-PgDown for our own devious ends (providing proper scrollback).

Sounds reasonable to me. I proposed the following modifications to (c):

• we also grab Ctrl-Up and Ctrl-Down (since this is what Ctrl-wheel sends in gnome-terminal)
• but we don’t grab any keys for scrollback while the inner application is inside an alternate screen.

Do I understand correctly that the plan here is to provide scrollback similar to what a regular terminal provides? That is, if I run a command with a lot of output, I can reliably scroll back with my terminal's scrollbars to see everything that was output by that command? That is a really important usability issue for me. Thanks!

Yes, Scott, that's the plan, although you won't be able to use your local terminal's scroll bars. For now you can use screen or tmux on the server side to get this feature.

This is a cool idea. Is it possible to support mousewheel too?

Yes, if we do it with Anders's amendment, it will support the mouse wheel.

Agreed. This is the only significant issue with Mosh at the moment. It's the only issue that has tainted my experience.

+1

+1

I agree. I'd much rather read a whole page of PGP garbage :)

I agree. I'd much rather read a whole page of PGP garbage :)

+1

(I ... just ... couldn't resist ...)

+1 to that

+1 for fixing scrollback in mosh (showstopper for me)

-2 Mkaysi

+1, I sometimes cat a file on the server to copy it locally and not supporting scroll back prevents this.

+1 for fixing scrollback (the only real problem with mosh so far).

+1 for fixing scrollback, -1 for mkaysi, I wonder why mosh can't just behave like ssh on this. I have huge directories I "ls" all day so I have to use ssh.

Like SSH secure shell, but allows mobility and more responsive and robust.

@ubershmekel: You could use screen or tmux on the remote side for scrollback. Or simply ls | less.

I wonder why mosh can't just behave like ssh on this.

I'm glad you asked. :)

SSH is simply conveying a stream of bytes from server to client; it doesn't care what the bytes represent. So the local terminal (XTerm or what-not) gets the entire history in order, and can scroll.

By contrast, Mosh tracks the _current_ state of the terminal on the _server_ side, and then synchronizes this representation between client and server. This is the key design decision which enables Mosh's unique features -- roaming, local echo, and better utilization of bad connections. On the other hand, it complicates some things which are simple in SSH's world of carrying bytes in order.

To support scrollback we will need to add history to this terminal state object, and augment the protocol so the client can request bits of history on demand, as the user scrolls. (Without doing it on demand, we lose a key advantage of Mosh over SSH, which is that commands which spew output will update at a fixed "framerate" rather than lagging the connection.)

This is certainly doable, and is obviously something that a lot of people want. But it's not really "just do the same as SSH" and it's not a trivial change. In the meantime, I think running screen or tmux on the server side is a fine workaround (and has many other advantages).

I must say that running screen on the server was exactly the thing I hoped to avoid with mosh. This is what I was doing with SSH when I was afraid that connection will be broken because of IP change or something. With mosh I hoped that I could just run it and everything else would be cared automatically.

You could maybe even integrate mosh with screen. :-)

@kmcallister

I wonder if mosh could grow an alternate mode where it skips all the pty magic and just acts like regular ssh.

This would of course remove the benefit of latency optimization, but I believe many people (at least myself) are only interested in the connection-persistence anyway. In this mode a display would be restored simply by playing back the last n bytes unconditionally. Keeping track of the local/remote buffer offsets in order to trigger the right amount of playback at the right times should actually be fairly easy then...

With mosh I hoped that I could just run it and everything else would be cared automatically.

You can run

mosh user@host -- screen -dR

This also helps with another problem. If a mosh-client dies unexpectedly (say, because the client machine lost power), the corresponding mosh-server will hang around uselessly. But running screen -dR will cause the other screen process to exit, killing that old mosh-server. You can of course make this more sophisticated with named screen sessions and such.

@m-o-e: What you describe is doable, but I'm reluctant to add alternative modes to Mosh which fundamentally change the operating principle. Perhaps something like autossh would meet your needs?

I tried using Mosh for the connection persistence, and nothing I read prior to using it gave me a clear indication that it was anything but an ordinary shell with an improved transport. When Mosh discarded some important output I had no idea what was going on, and I wasted a few days (calendar time, several hours actual troubleshooting time) looking at everything else because it didn't occur to me that a tool for persistent connections and better latency would also throw away my data. After that, I can't trust you, not because the way Mosh works is unreasonable, but because the way it is described fails to convey that you can't count on receiving the complete output of any command. (I suspect it also fails to convey the goals that drove the decision to make it work that way, but that's not important.) At the very least, the conditions for discarding data should be given a prominent position where no new user who reads anything about Mosh could reasonably fail to miss it. If I had read such a notice before my output was lost, even if I hadn't understood the warning I would have traded those days of aggravation with a moment of "Oh _that_'s what that meant!"

I cannot agree with Polyergic. I think site is nicely done and also interface with the underlined characters nicely tell that there is some prediction being done. I didn't have problems of not understanding what is happening. The only thing which surprised me was that --predict=never still didn't make output work as I was used.

So I would maybe just urgue for a switch (I can then bash-alias) which would transfer everything. It can still predict.

So I see three options here:

• prediction + not transfer everything (useful for high latency, low bandwidth links)
• prediction + transfer everything (useful for high latency, high bandwidth links)
• no prediction + not transfer everything (useful for just connection persistence)

I fall into 2. category. Trans-Atlantic links to Europe have 100ms latency, but they are fast. I would rename mosh to tash in this case: trans-atlantic shell. :-)

@kmcallister

Emulating a terminal (screen) inside an emulated terminal (mosh), in order
to emulate native functionality (scrollback) of the enclosing terminal emulator
(xterm, iterm) does not and can not possibly result in an acceptable user experience.

That is the underlying problem here. Of course neither is mosh to blame for
30 years of stagnation in the terminal emulator business, nor can it cleanly
resolve the situation from where it's currently sitting in the stack.

Hence my proposal of a 'dumb-mode', as a short-term bandaid
for the next few decades.

@mitar, I don't see any disagreement between what I said and what you said; restating things tersely, what I see is this:

I said: Mosh loses data in an unexpected way; descriptions of Mosh should set expectations to match its behavior.

You said: The Mosh website is nice; the prediction indicators are nice; an option to transfer everything would be nice.

What am I missing? Did you see a clear notice somewhere that Mosh won't keep all of the output of your commands?

@m-o-e

Emulating a terminal (screen) inside an emulated terminal (mosh), in order to emulate native functionality (scrollback) of the enclosing terminal emulator (xterm, iterm) does not and can not possibly result in an acceptable user experience.

Well, could you describe what about the user experience is unacceptable? This would be useful information for us.

In general, the world of computers is full of apparently ridiculous levels of nesting and emulation which nevertheless provide a perfectly fine user experience.

@kmcallister

Foremost the frankenstack does not support native scrolling. That's a showstopper.
'copy-mode' and virtual scrolling hacks are no substitute. There's also a plethora of more subtle
issues, but you (as the author of a terminal emulator) don't need me to tell you about those. ;)

As said, I'm not blaming mosh for the ridiculous terminal-situation of today - that's been dire
since long before mosh even existed. Given the project scope mosh had little choice other
than crouch on the shoulders of gnomes, like everyone else, and for that it isn't even faring too bad.

I'm just saying that with the supposed 'dumb'-mode mosh might work for those of us who have
no problems with latency and who would like the persistence, but can not tolerate a broken scrollback.

A bandaid on top of the bandaid, so to say.

Just until someone finally takes a heart and supersedes VT100 terminal emulation altogether...

I, also would love to have a "dumb" mode that lets me use normal scrollback in my terminal window to look at the history of what I did before or scroll through the output of a large command.

I haven't done vt100 stuff since my BBS days, so please feel free to smack me down, but couldn't you do both things? Every time your screen state changes in such a way that you have to scroll a line up off of the screen, couldn't you just go to the bottom and do a cr/lf, scrolling the top line off the screen and into scrollback, then continue syncing the screen state like you do now?

Clearly, we could lose some output if we go offline and stuff scrolls off the page on the server, but I'd be OK with that. So long as it worked while I'm online and interacting with the shell, I'd be happy. I'd be even happier if you kept track of when stuff scrolled off the top on the server side that we didn't see and scrolled off some sort of marker like "mosh: 60 lines scrolled on server while you were offline", but that's certainly in bonus round territory. :-)

To be clear, I'm expressing a preference here. If it's hard, and conflicts with your goals, then that's fine too. I'll use mosh regardless, because the stateless connection stuff really complements the way I work. :-) Thanks for creating this!

@timspencer I think what you're suggesting sounds reasonable but may not be easy to implement. My understanding is that mosh doesn't keep track of the byte stream, it just looks at the current state of the terminal and computes a diff with the previous state, and sends updates to the client, periodically. If you cat /dev/urandom, the screen will be updating very quickly, but mosh won't send _everything_ to the client, it'll just take regular snapshots and send diffs. At least that's my understanding, I haven't read the source code.

Having said that, it would be awesome indeed to have a streaming mode where mosh just streams everything and only does connection persistent plus its prediction things.

Can we separate this into two issues? The issue I reported is that mosh should put the terminal into alternate screen mode. This is a clear bugfix that we can implement today. It’s required for gnome-terminal’s mouse-wheel-to-arrow-key emulation in curses applications. (Don’t confuse that with the fancier xterm mouse-event protocol that nobody uses.)

The second issue that’s grown out of this thread is that mosh doesn’t support useful scrollback history. It’s true that one side effect of putting the terminal into alternate screen mode would be that mosh’s useless scrollback history would become inaccessible. I consider that a feature, not a bug. If we later want to go put a lot of work into designing a system to add useful scrollback, that would be awesome. But that’s a totally separate feature request, and it’s not needed for what I understand to be the common case where the user is just running screen inside mosh anyway. I propose reopening #122 for that.

We should fix mosh now to put the terminal into alternate screen mode, with a command-line switch to disable it (like less -X) for people who think broken scrollback is more important than a working mouse wheel.

Anders, ok, I'm sold on this for 1.2.4 if it just means adding smcup and rmcup to Terminal::Emulator::open() and Terminal::Emulator::close(). Would you be willing to submit a pull request? (I assume we want the actual terminfo calls to remain in src/terminal/terminaldisplayinit.cc).

I consider gnome-terminal's mouse wheel to arrow key emulation to be a horrible bug. There are lots of people who agree with me: https://bugzilla.gnome.org/show_bug.cgi?id=518405

Unfortunately, the GNOME developers do not agree with the bug interpretation, and neither it seems does andersk. I will try to convince you (futilely, I suspect) that it is indeed a horrible bug. The reason why mapping wheel events to arrow keys is bad is because scrolling the mouse wheel is supposed to be a _nondestructive_ operation. My mental model of the mouse wheel is that scrolling the wheel is supposed to only change your view of the terminal scroll buffer. It should never alter the terminal state itself. Unfortunately, in many situations, such as IRC clients and many other scenarios which are mentioned in the GNOME bugzilla thread, the GNOME behavior of emulating arrow keys does in fact result in permanent loss of an application's input buffer state whenever the mouse wheel is bumped. For example say I am in the middle of typing a line when I bump the mouse wheel. The mouse wheel infuriatingly triggers a keyboard arrow press, which wipes out the line that I was typing. Fixing the individual applications is problematic given the large number of applications that exhibit the problem.

The fact that mosh fails to use alternate screen mode has been a huge blessing for me, because it means that accidental mouse wheel events don't destroy IRC client state from inside mosh. Since all of my IRC client usage occurs within mosh, this (unintended?) feature of mosh completely neutralizes the underlying GNOME bug for me. I would be very sad to see this behavior go away.

If you do choose to implement this completely demented idea, please (as andersk suggests) provide a switch to disable it. It's not that I prefer broken scrollback. It's that I hate data loss above all other considerations, and unwanted arrow keys result in data loss.

(Regarding the second issue in this bug, wherein mosh causes data loss of scrollback contents, I of course strongly support any efforts to change mosh to preserve scrollback data. There is nothing in the world that is more important than avoiding data loss.)

davidjao: gnome-terminal already provides a checkbox (Edit → Profile Preferences → Scrolling → Use keystrokes to scroll on alternate screen) to disable the arrow key emulation entirely. But nobody disagrees that there might as well be a command line switch for those who need to work around this on a per-application basis for some reason.

This checkbox only exists on Ubuntu and derivatives of Ubuntu. It is not included in the upstream gnome-terminal, and other distributions such as Fedora, Debian, Arch, etc. do not provide it. Of course you can patch it in yourself, but that is a pain.

I understand that we all agree a command line switch is desirable but I am worried that it might be left out or regarded as unimportant. That's why I wanted to comment on why it is important.

Thanks everyone, the --no-init option works perfectly to disable alternate screen mode for those of us who don't want it.

In the spirit of keeping the documentation up to date, could we mention in the man page (in the ENVIRONMENT VARIABLES section) that the MOSH_NO_TERM_INIT variable inhibits smcup/rmcup?

For me the "--no-init" option doesn't resolve the scrollback problem with mouse wheel.

"--no-init" is completely broken here with the XFCE terminal: some part of the output is forgotten in history, and the scrollbar gets updated inconsistently. Why can't mosh just behave as ssh does? Being opinionated is fine, but it would also be nice to benefit from the networking improvements without having different terminal emulation decisions forced on the user.

The

mosh user@host -- screen -dR 

workaround works. What would be the equivalent command for using tmux instead of screen and ensuring no tmux processes are left behind when I disconnect?

Thanks.

Actually I spoke too soon. The screen workaround has issues. If I use it in two separate terminal windows, one after the other, the second window hijacks the screen in the first window. Would be great to have scrollback to eliminate the need for this. Thanks.

@dtenenba, this is not a support forum for tmux and screen. Read the manpages (tmux(1), screen(1)), especially the parts about the -d option to tmux attach-session, and the -d, -r, -x options to screen.

I would like to call this article into attention. It describes a nice simple setup combining mosh and tmuc resulting in a working scrollback history (with mouse) on terminals supporting xterm mouse. On OS X, that's iTerm or even Terminal.app with easySIMBL and MouseTerm plugin.

It seems this is still not really implemented? Running mosh -n --no-init still disables scrolling for me? (Mac OS X with Terminal.)

--no-init only exists to restore the pre-1.2.4 behavior of not disabling the terminal’s scroll bar, to appease those who believed that functionality was being lost. Mosh has never been able to guarantee that the terminal’s scroll buffer will actually be filled with anything, much less anything useful, because of the way it optimizes frame deltas in its state synchronization protocol. See #122.

It would be really nice if mosh supported scrollback. I'm using mysql on the server and Describe's output is longer than the screen so it's impossible for me to see the top. Oh well, back to ssh I guess.

In the mysql cli you can just do pager less and the output will be redirected to less instead of being printed directly.

@tsuna Thank you! That command is awesome

any hope that this will be fixed someday?

The --no-init flag sometimes works sometimes doesn't. We are hoping to see a native scrollback support with Mosh.

Latest iTerm2 on macOS Sierra 10.12.5

Yea this is a pretty big deal for me. I will use this once this obvious showstopper is fixed.

Really not sure what all the fuss is about, if you want scrollback use screen or tmux, they are wonderful tools, and using them appropriately will let you do SO much more than trying bolt more features into mosh. The unix philosophy for tools, do one thing well, is PERFECTLY illustrated in this case. https://en.wikipedia.org/wiki/Unix_philosophy

I just tested this on my local machine connecting to another machine. I connect using mosh, reconnect to tmux using -- tmux attach as the argument of the connection string, and I'm reconnected to my session with the ability to scroll back through history, scroll my tmux "window bar" to go to different panes, in short everything that people have been asking for above WITHOUT any changes to mosh.

If you are scrolling back through previous commands you are probably using only mosh or you are in screen. It does this whether you connect via SSH or mosh, because it uses the "alternate screen" itself. I like screen, but tmux is much better for multiple commands and sessions, and handles scrolling and history in a far more sane manner in my opinion.

@dragon788 good to hear that. But are you able scroll up using mouse
because you mentioned you're able to scroll using "window bar" which I
think not an issue here.

On Sat, 21 Oct 2017 at 6:26 AM dragon788 notifications@github.com wrote:

Really not sure what all the fuss is about, if you want scrollback use
screen or tmux, they are wonderful tools, and using them appropriately will
let you do SO much more than trying bolt more features into mosh. The unix
philosophy for tools, do one thing well, is PERFECTLY illustrated in this
case. https://en.wikipedia.org/wiki/Unix_philosophy

I just tested this on my local machine connecting to another machine. I
connect using mosh, reconnect to tmux using -- tmux attach as the
argument of the connection string, and I'm reconnected to my session with
the ability to scroll back through history, scroll my tmux "window bar" to
go to different panes, in short everything that people have been asking for
above WITHOUT any changes to mosh.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mobile-shell/mosh/issues/2#issuecomment-338336608,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABhWeSFAPBiXYl3BA5W4lb43V_fw2f_Lks5suR4HgaJpZM4ABSOa
.

>

Eduardo D. Bergavera, Jr.
Linux Admin
Email: [email protected]
OpenID: https://launchpad.net/~edbergavera
Github: https://github.com/edbergavera

The fuss has nothing to do with lack of scrollback functionality. The fuss is that in alternate screen mode, mouse wheel events destroy the current command buffer because a mouse wheel event is interpreted as an arrow key. This is devastating because it means accidental scrolling leads to data loss.

Your suggestion seems to be "don't use GNU screen" but this advice is untenable for many obvious reasons.

@edbergavera I'm scrolling back using the tmux history via copy-mode (which preserves the command output on the remote, which IMO since it is where the commands are running and where it really matters is where the history should be). I believe you can use the mouse scroll wheel if you have a plugin for tmux that interprets the scroll wheel escape codes as a signal to enter copy mode and scroll, or you can simply Prefix+[ or whatever you bind to enter copy mode and then scroll with your mouse assuming your terminal isn't capturing the events and forwards them to the server intact. Prefix+Esc is another equivalent.

What about a flag telling how much history to load at start (like tail -n)?

I'm sad that this is still open, I have been chckeing in every couple of years to see if native scrolling support have been solved but untill then I can sadly not use this.

To clarify, I only care about reliably reconnecting after network outage without prorams on the remote host terminating.

I can't believe this is never getting fixed :( It's a nightmare. ssh dies. mosh isn't usable.

Installed mosh to use it at work with an unstable 4G connection. Looks like it's working great on poor connections but the missing scrolling features makes it a no-go for me. Instantly uninstalled it as I prefer to relog-in into SSH few times a day than miss this critical feature.

@mr-propre It really is a basic fact of usability. I use it to connect to Spark clusters because ssh fails and then I use screen with CTRL-A, Escape and then page up/down to scroll but it is irritating as hell and the buffer is too small.

Not sure if it was mentioned here already, but if you're affected by this issue you may want to take a look at Eternal Terminal as an alternative.

Folks -- you realize you can adjust the amount of scrollback that screen and tmux save?

This is a solved problem for most people (who are using screen/tmux, or even less, on the server side). Mosh is probably not getting its own remote-scrollback protocol anytime soon.

I'm aware. It just sucks the client doesn't handle this like every other
one I've ever heard of.

Thanks,
Russell Jurney @rjurney http://twitter.com/rjurney
russell.[email protected] LI http://linkedin.com/in/russelljurney FB
http://facebook.com/jurney datasyndrome.com

On Tue, Aug 13, 2019 at 12:54 PM Keith Winstein notifications@github.com
wrote:

Folks -- you realize you can adjust the amount of scrollback that screen
and tmux save?

This is a solved problem for most people (who are using screen/tmux, or
even less, on the server side). Mosh is probably not getting its own
remote-scrollback protocol anytime soon.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mobile-shell/mosh/issues/2?email_source=notifications&email_token=AAAKJJKV4Y2R4PB2E6UWYL3QEMGPNA5CNFSM4AAFEONKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4GZK3I#issuecomment-520983917,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAKJJMBSF2QEQUAEBR5X5TQEMGPNANCNFSM4AAFEONA
.

This issue is really annoying - until you learn to use tmux. Then it's no longer an issue.

I’m sorry but I disagree. From my POV having to use tmux is a bit of a cludge. If I wanted to use tmux, I’d be good enough with ssh + tmux.

Actually I’d be curious on what’s the advantage of “mosh+tmux” vs “ssh+tmux”?? What people think?

Most of the same mosh benefits still apply when using tmux:

• Seamless connectivity when your client changes networks or your client machine comes out of a suspended/hibernated state
• local echo
• better control-C handling

I tried tmux and screen but they don't fix the biggest problem I have with mosh: I can't paste Python code into the terminal. I'll make a separate issue: https://github.com/mobile-shell/mosh/issues/1066

Myself, I don't object to using tmux, but scrolling using tmux is laggy as it requires waiting for the remote server to send the updated screen contents. One of Mosh's core selling points is that it provides better interactivity than ssh on slow or unreliable networks. However, when it comes to scrollback, relying on tmux provides worse interactivity than local scrollback.

How hard would it be to add a rollback to mosh? What is involved?

but scrolling using tmux is laggy as it requires waiting for the remote server to send the updated screen contents

If mosh ever learns how to do scrollback, I'm imaging that it would have to do the same thing, so I don't quite understand this complaint.

Why would it have to do the same thing? In principle Mosh should be able to keep a local copy of the scrollback buffer. I suppose there might be issues if something is spamming the terminal fast enough that the client doesn't receive all the text (since Mosh intentionally throttles screen updates to a fixed framerate). But that's solvable; Mosh would need some sort of algorithm to sync scrollback contents with the server, ideally with a lower priority than screen updates.

It's 2020 and issue #2 still open... oh boy...

Really not sure what all the fuss is about, if you want scrollback use screen or tmux, they are wonderful tools, and using them appropriately will let you do SO much more than trying bolt more features into mosh. The unix philosophy for tools, do one thing well, is PERFECTLY illustrated in this case. https://en.wikipedia.org/wiki/Unix_philosophy

@dragon788 if anything, this shows the downsides of _not_ following the Unix philosophy. Mosh breaks the Unix philosophy by doing way more than just one thing, so it ends up in the position where it's a terminal emulator in its own right, but a very limited one without scrollback support.

This is fine for a real terminal emulator (hell, I use st and I try other terminal emulators without scrollback), but when Mosh does it, it breaks existing scrollback, which goes beyond simply not supporting scrollback. I'm already using tmux to house the Mosh session, so why should I start another tmux session on the server end as well?

Now the _server_ (and that's _every_ server you want to connect to) has to have tmux or similar installed just to work around Mosh's _breaking_ of scrollback (not merely its lack of support for it), so how is that following the Unix philosophy, exactly?

ssh sets the standard here. Mosh violates that standard, requiring the addition of an entirely new piece of software most users don’t want on the server, so people don’t use Mosh nearly as much as they would if it supported scrollback the way users expect because alternatives support it. There is a strong attitude of “not my problem” despite this being a very real problem for the majority of Mosh users that limits the amount of impact the work of Mosh contributors have with the project. Obviously open source is about putting your money where your mouth is and adding what you need. I’m not in a position to add this feature so I and many others like me don’t use Mosh unless we absolutely have to. I hope someone steps up and adds this feature because it is a major gap in Mosh as an open source project and its availability will dramatically increase Mosh adoption and make a lot of users very happy.

The way you’ve closed the ticket means that nobody is going to step up and make that contribution, which is unfortunate. The least you could do for your community is to stop passing the buck and misusing Unix philosophy and simply admit that you don’t feel like adding it and let someone else step up and do so. “Not my problem” may make you feel better about having fewer open tickets but this attitude undermines the project and it’s users. This ticket has 76 comments. How many of your other tickets have 76 comments? I suggest you think about why you contribute to open source and whether you value your community at all with this attitude.

Please open this ticket and at least let someone else step up and add this essential capability.

Really not sure what all the fuss is about, if you want scrollback use screen or tmux, they are wonderful tools, and using them appropriately will let you do SO much more than trying bolt more features into mosh. The unix philosophy for tools, do one thing well, is PERFECTLY illustrated in this case. https://en.wikipedia.org/wiki/Unix_philosophy

@dragon788 if anything, this shows the downsides of _not_ following the Unix philosophy. Mosh breaks the Unix philosophy by doing way more than just one thing, so it ends up in the position where it's a terminal emulator in its own right, but a very limited one without scrollback support.

This is fine for a real terminal emulator (hell, I use st and I try other terminal emulators without scrollback), but when Mosh does it, it breaks existing scrollback, which goes beyond simply not supporting scrollback. I'm already using tmux to house the Mosh session, so why should I start another tmux session on the server end as well?

Now the _server_ (and that's _every_ server you want to connect to) has to have tmux or similar installed just to work around Mosh's _breaking_ of scrollback (not merely its lack of support for it), so how is that following the Unix philosophy, exactly?

This. So much this.

Let’s bring this conversation back down from low Earth orbit, guys. The reason Mosh doesn’t support scrollback has nothing to do with philosophy. It also has nothing to do with whether this ticket is open or closed—there’s already a ticket open for scrollback, and it’s not this ticket, which was about alternate screen mode. It has everything to do with limited developer time. If you’ve read the Mosh paper, you’ll understand how the way Mosh prioritizes interactivity makes delivering usable scrollback a challenge, so it was left out of the initial implementation and nobody has had time to add it since. If we had infinite time to work on Mosh, a scrollback feature would likely be a priority. Nobody is stopping you from developing this functionality if you are interested, and as always, a well-designed, well-implemented pull request is likely to be accepted. But complaining on a closed issue isn’t going to make that happen any faster.

@andersk I think it is this priority of interactivity that is seen as a deviation from the unix philosophy. Mosh does both connections that does not die (a feature I would realy like) and interactivity (a feature whose price, a scrollback that is not a pure compleate ascii stream, I am not willing to pay). What peaople seems to be asking for is the reliability without the interactivity as they think alternat screen mode is a to high price to pay.

Pragmatically, I'm not really interested in whether Mosh follows the UNIX philosophy or not; all I know as a user is that it's a great piece of software to _use_, except for this glaring flaw.

I'm not here to beg the author to add the feature for free, I understand that it is what it is and I'm not owed code or time or effort or anything.

My comment was _only_ criticising the claim that (paraphrasing) “Mosh shouldn't do this because it goes against the Unix philosophy”; my counter to that is that the whole reason Mosh has to do this in the first place is exactly _because_ it's already gone against the Unix philosophy. I'm not making a judgment on whether that's good or bad, I don't know what all the tradeoffs were and what _not_ following the Unix philosophy bought Mosh.

My solution in the meantime is to just not use Mosh. I hope I'll be in a position to set up a bounty in the near future now that I'm aware of Mosh again and what's standing in its way for me. Beyond that, I'll just keep using SSH and respectfully let the author know that this is the one thing standing in the way of my using Mosh (people generally care that some people aren't benefitting from their work until those people are rude).

@rjurney I'm pretty sure the person citing the Unix philosophy is not the author. There's no reason to be so harshly critical.

The author also does have an open issue on scrollback. It's locked because the discussion is pretty much over. We all want it, but none of us are gonna have it until some of us implement it. But the issue is open. It comes down to all of us now, not just the creator.

I am going to unlock the open issue about scrollback, since it's had a chance to cool off. However, please avoid commenting on that issue (or this issue) if there is nothing new to add. There are "reaction" buttons in github that can be used to express your interest (which don't spam the whole thread), and comments like "+1" aren't useful. We know this is a very important issue to some people and that running screen/tmux on the server isn't always a convenient or acceptable solution.

Comments about unix philosophy are interesting, but are definitely __off-topic__ for this github issue tracker. (However, you're welcome to join our #mosh IRC channel on freenode to discuss such things).

Not sure if it was mentioned here already, but if you're affected by this issue you may want to take a look at Eternal Terminal as an alternative.

Eternal Terminal doesn't have a binary package for centos 7, I recently spend hours to compile it manually and give up finally.