mosh prevents the use of scrollback

[taralx]

If I use mosh to connect, and then run a command with a lot of output, e.g. ps, my scrollback buffer doesn't get any of the overflow. This is sad-making -- I don't always know when a command will produce a lot of output, and, additionally, I like scrollback for seeing previous commands' output.

[keithw]

Thanks. The're a compromise here between skipping frames for speedy terminal support and wanting to have everything sent to the local terminal, and mosh picks a particular (not necessarily perfect) point on that spectrum. The workaround for now is to run "screen" or "tmux" on the remote end and use that for scrollback.

[wjessop]

I realise this is a closed issue, but not seeing all the output of a command is a real blocker for me. If I run a command I need to see all the output, having to load up screen or tmux with it's non-native scroll support doesn't really work.

Is there no way we could set an option for not discarding all the output?

[taralx]

I understand why this is closed -- mosh doesn't actually send the stream to the client, so dumping all but the last screen is correct behavior.

I would love an option to have an extended "screen" which included X lines of scrollback, but that's more of a feature request, and is hard.

[keithw]

We are working on this for mosh 1.3 and will try to do the most pleasant thing possible. You can follow this issue at #2.

[ShadSterling]

Without seeing the output, I don't know what my command did. This is completely unacceptable, especially without any warning. I will not use mosh again.

[jessejoe]

Since #2 is now closed, and this issue was not affected, can this possibly be reopened?

[xapple]

It's been about a year now that I have my eye on mosh waiting for this feature to be implemented. I think mosh could become an essential tool -- but not until this works. Let's face it: without scrollback it's pretty useless in the real world (except when you are trapped in a lift maybe).

[KamilKedzia]

Scrollback is essential in everyday use. I was about to make mosh my primary tool for remote work but as I discovered this flaw I'm back to ssh. I might consider getting back to mosh when working in extremely poor networking conditions but giving up scrollback for the possibility of having single ssh session at work, commuting and at home is not an option.

[ViViDboarder]

I just noticed this as an issue, but using gnu-screen isn't a big deal for me. Maybe I'll look into tmux or something too.

Some resources for those of you not familiar. Getting multiple windows out of one SSH session is a pretty good feature anyway for those of you not using it.

http://www.howtogeek.com/58487/how-to-easily-multitask-in-a-linux-terminal-with-byobu/
http://www.howtogeek.com/114582/2-alternatives-to-gnu-screen-for-linux-terminal-multitasking/

[FiloSottile]

I guess that the scrollback does not need to be as fast as the actual terminal, so mosh might cache on the server and then slowly stream to the client that would catch up eventually.

[hamiltont]

+1 - This issue is also preventing me from using mosh 100% of the time. Do any shells/terminal programs exist with APIs to deal with native scrolling? Perhaps something to get the ball rolling in this case would be a proof of concept for an easy client, instead of searching for the general solution for every shell

[andersk]

Even if this is implemented, you’re most likely not going to get native scrollback. Native scrollback would require sending all the scrollback data to the local terminal in sequential order, which would totally erase Mosh’s features of graceful packet loss handling and working Control-C. If you don’t want Mosh’s features, you might as well just use SSH.

The plans we’ve discussed (see #2) involve adding new Mosh-specific key bindings to access a dynamically loaded server-side scrollback buffer, similar to what you can already achieve by running screen inside of Mosh.

As far as I’m aware, no code has been written (and repeating “+1” over and over isn’t going to magically cause code to become written).

[marty1885]

@RipperSK The root cause of not able to scroll is caused by mosh entering a "alternative screen" mode. It can be disabled using the --no-init flag (see the doc). Just alias mosh='mosh --no-init' and the problem will go away.

[eminence]

The root cause of not able to scroll is caused by mosh entering a "alternative screen" mode.

This is not true. The root cause is that the mosh model is fundamentally incompatible with a scroll-back buffer managed by your local terminal.

Beautiful. Could someone please explain in Layman's terms what are the drawbacks?

The drawback is that your local scrollback might be "incomplete". For example, try cating a large text file. With mosh, probably only the last page of the file will appear in your local scrollback. If you use ssh, you'll have the entire file in your local scrollback. This is a feature of mosh (not a bug)

Edit: If you have any questions about this, feel free to join our IRC channel (#mosh on freenode) to chat

[eminence]

Hi all, I am marking the above comments as "off topic". I want to reiterate a few things:

• I don't consider using --no-init as a way to get reliable access to a local scrollback buffer. You can of course use this option if you understand that it does and its limitations, but if you're having problems with --no-init, this issue is not the place to discuss those issues. Please open a new issue, or find us on IRC to chat
• We definitely know that people want this feature, it's one of the most requested features. But just because ssh is designed in a way to support a local scrollback doesn't mean that mosh can make use of this. I know we've left this issue open for many years, and this might have signaled that we intend to implement this feature. But please interpret this open issue as simply an acknowledgement of the request. We do not have any intention on implementing this feature
• This issue likely has hundreds of subscribers. Please think very carefully before commenting -- does the comment/question you are about to add substantially contribute to the conversation? If not, please open a new issue with your question.

Thanks all

[FFAMax]

Use case: After working from location with a high speed Internet took the laptop and moved to bus.
What changed? Right, connectivity: from stable and high speed to -> unstable and sometimes low speed.
Therefore, if we talk not about ignoring all these comments but about hearing and follow to the initial logic of mosh, I see we need another mode. Mode which will determine behaviours. If we can pass all data to client (high speed and stable connection) - why not do that? If mosh detected connection got jitter/delays/losses then -> switch to legacy mode. If connection restored -> switch to high performance mode. Also may be useful with additional options like --mode-hybrid if users really want use this feature. Because I see variants when people may wanna save unneeded traffic even with a stable connection (for example in airplane, roaming, etc).

btw: tmux is another - this require exchange with a remote side.
Example: I worked from workplace with a stable connection, had same scroll buffer, after jumped to the bus - if scroll buffer not on my local terminal, it will relay on network reachability instead of to be available locally. :)

[achernya]

Unfortunately the problem here is not network communication, but rather mosh's construction of being a terminal emulator. Native scrollback requires not just a reliable channel, but also not being a full terminal emulator.

This issue is marked as a feature request and remains open in the mosh bug tracker slated for some future milestone. This means that the mosh team has an interest in working on this, but is not committing to a timeline for its completion.

To folks that are interested in this feature: we're interested in proposals to fix this and PRs to do so, but please don't comment on this issue attempting to motivate the use case further. Rest assured that you've been heard -- feel free to 👍 up the top comment to express your support.

[eternaleye]

Native scrollback requires not just a reliable channel, but also not being a full terminal emulator.

(emphasis mine)

I'm not sure this is strictly true? Specifically, as far as I'm aware it's more a matter of what specific terminal one is emulating. For example, the VT520 has a "desktop feature" to "Review previous lines"; this keeps a "Review Previous Lines Buffer", which (quoting section 2.8.3 of the EK-VT520-RM document (PDF)) behaves as follows:

The Review previous lines feature when selected re-arranges page memory into a single page and a scroll back buffer (transcript). Lines of text scrolled up from the first line of the page are saved in the scroll back buffer (replacing the oldest lines saved if any). Pressing Control with the up or down arrow keys pans the screen window up or down allowing you to view lines previously scrolled off the top of the page up to the number of lines saved in the scroll back buffer. If the page size is larger than the window size, pressing Control with the up arrow key first pans to the top of the page and then pans into the scroll back buffer.

Any time lines in the scroll back buffer are available, a small down and/or up arrow appears at the lower right position of the status line to indicate there are additional unseen lines of the page below or above. When any text is received from the host for this session, the screen window is automatically repositioned to show the single page before the display is updated. Switching sessions does not automatically reposition the screen allowing you to view the scroll back data in one window while working in another. The number of lines that can be saved in the scroll back buffer is one page less than the total number of lines (in 25 line pages) allocated to the session virtual terminal. The factory default for Review previous lines is disabled.

You cannot copy and paste from the scroll back buffer.

As far as I can tell, this functionality provides perfect license for a VT520 emulator to provide a line-by-line scrollback buffer. I've not yet gone digging enough to tell when such functionality was first introduced (i.e. whether it predates the VT520). At that point, emitting lines from said buffer into the client environment is merely a matter of the emulator's choices regarding platform integration.

As for the first half (reliable channel), I'm not convinced of that either: in particular, the visible portion of the scrollback buffer could be the "synchronized state", while the scrollback buffer itself could be "server-private state". At that point, you no longer need a reliable channel either. This would relax the "local" part of scrollback buffer, but could possibly recover it by remembering what had already been filled from the terminal-emulation scrollback buffer into the local scrollback buffer, and backfilling via range requests. However, in order to survive unbounded periods of connectivity loss, this would require an unbounded server-side buffer.

[achernya]

The problem is not the VT520 that mosh emulates. The problem is the outer terminal requires a line-oriented output, of every single line. If you want "native scrollback", then mosh needs to deliver, reliably, every single event that happened server-side to the client's outer terminal.

The scrollback buffer can't be synchronized in the way you describe because the scrollback buffer is part of the outer terminal. There are no events (to my knowledge) that the outer terminal sends to mosh to generate scrollback; that's why things like screen and tmux have their own scrollback mechanisms. What you're asking for essentially amounts to making a "moshterm" GUI program.

[zen2]

As far as I have understood mosh implementation uses two buffer: one on client and one on server side and the sync mechanism is using a diff/patch of both buffers to keep in sync.
So I suppose that the buffer size is equal to the number of characters displayed on your current terminal so basically height x width characters.
On another side, I can see that mosh doesn't interpret the classical keys input of shift+PageUp/PageDown natively so these keys are not used at all since it is not even treated natively by readline library.

So I wonder if it is not possible to implement a scrollback by pages simply by setting the buffer size by multiplying the size of the buffer by an integer in order to make the buffer represent a finite number of full pages for the current terminal and interpret keys to change page by page or line by line. Like it the sync mechanism continue to do is job and a simple offset applied permit to display the scrollback. The drawback is that won't work at all if you resize the terminal but actually mosh doesn't handle it too for its buffer so I don't think it is a real problem any way.

It is a similar that the way used for old school vertical bitmap scrolling where you simple change offset of the video memory pointer on a virtual screen more higher than real screen.

[AkechiShiro]

No solution was found possible for this I guess ? as I've read @achernya's latest comment right ? Maybe this feature is simply not possible and we should use screen/or any other terminal multiplexer for scrollback buffer ?