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?

[enagorny]

+1 for such functionality

[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/

[garrettreid]

Another +1, the lack of scrollback is a usability issue for me. I realize this feature is probably a lot of work, but it would really improve my life, let me use mosh in more cases, and probably solve world hunger.

[JeffBezanson]

+1 I can make do with the screen workaround but this would be great.

[nikolay]

+1

This "feature" is a major blocker. If I have to run screen myself, honestly, there's little value in mosh as screen already solves the dropped connection issue and I can resume where I left without all the negatives like high latency and weird cursor behavior.

[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.

[jjn2009]

+1 I find the lack of scroll back to be pretty unacceptable as well.

[bufferunderflow]

no backscroll, hulk SMASH!!!

[zwass]

+1

[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

[mkawalec]

Just to add one more voice to this stream of lament, I will happily use mosh once this feature is added. It doesn't really work for me in this state.

[ghost]

Scrollback is a major feature and without it mosh will not be fully functional tool. I understand limitations but this should be configurable for user. Sorry, I have to back to ssh for now.

[Nishith]

+1 Adding to the chorus.

[otto2704]

+1 me too (especially that it should be configurable. eg maybe not necessary on a phone, but essential on a linux box in my eyes)

[NathanielCapital]

+1 Without scrollback feature, the mosh session doesn't really feel persistant, the workaround of tmux and screen is really very very inconvenient in some cases, like now I am using mobile phone to connect. You can simply scrollback by swipe if the feature is there, but using hot-keys like ctrl-a [ make the an mental interruption in the workflow.

[ekenberg]

Any news on this? Native scrollback (ie swipe in Mac OS X Terminal) is essential for an efficient workflow. Please consider making this feature a priority! Thank you.

[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).

[ekenberg]

@andersk Thank you for the update. Sorry about native scrollback, I didn't think that through before posting. I just started using Mosh, and the only thing I care about is being able to survive network roaming. Anyway, thanks.

[JimmySpivey]

+1

[nicowilliams]

My proposal is to run a screen on the client side, mosh inside that screen, then screen again on the server side. s/screen/tmux/g to suit.

Then you get scrollback on the client side, at least for apps that don't use the alternate screen.

That might seem ugly, but I already nest multiple screens anyways :)

[ViViDboarder]

Or spoof the client screen size has 3x (configurable?) the actual height and just display a window of that so that the client can then scroll freely within that.

Not sure if mosh actually works this way. I tried digging into the source but didn't get very far.

[tomlouie]

@ViViDboarder: I like your idea of the spoofed client screen size. The default value could be "spoofed size"="actual size", so that users who don't care about scrollback can enjoy mosh as it is today. The users who do care about scrollback can set "spoofed size"=3 x "actual size", and can use native scrollback.

Both groups of users happy.

[bassu]

I started using mosh recently and now this problem (combined with the problem of detached sessions) is bothering me a lot. If terminal multiplexers like tmux, dvtm, screen , yada, yada, are to be recommended as alternative on server side then why should one even bother using mosh? Just for rapid echo and volatile connections? No, thanks! Those terminal multiplexers have been doing the job quite well for years. That being said, I don't see any real advantage of using mosh at the time until the critical problems are fixed and/or things improved.

[andersk]

@bassu, I started reading your comment recently but I realized that my hunger is bothering me a lot. If existing sandwiches like peanut butter & jelly, BLT, and corned beef are to be recommended as alternative on lunch plate side then why should one even bother reading your comment? Just to hear the software I helped develop insulted by someone on the internet? No, thanks!

I can’t imagine what you hope to accomplish by telling the developers that their software is useless.

[bassu]

@andersk I did not say or mean to say that the software is useless. It certainly has the reasons for its creators to develop it and may be the consumers too. All I meant was, I don't find it befitting for myself in the situations I mentioned and some people would agree. But as the makers of software, you should be open to all sort of feedback including negative critics. You probably should not make anything if you are not wanting to see any sort of feedback or a review at all!

[dwiel]

won't a spoofed client window size break other things, like emacs and vi?

[nicowilliams]

I started using mosh recently and now this problem (combined with the problem of detached sessions) is bothering me a lot. If terminal multiplexers like tmux, dvtm, screen , yada, yada, are to be recommended as alternative on server side then why should one even bother using mosh? Just for rapid echo and volatile connections? No, thanks! Those terminal multiplexers have been doing the job quite well for years. That being said, I don't see any real advantage of using mosh at the time until the critical problems are fixed and/or things improved.

Hmm, what? Rapid echo and not having to reconnect due to roaming are the killer features here. If you were already used to using screen/tmux then lack of local scrollback is not an issue at all, and having it would not be helpful.

It's only when you're not used to using screen/tmux on the remote end that lack of local scrollback becomes an issue. Of course, one of the main reasons for using screen/tmux was the constant need to reconnect, which with mosh goes away, thus drawing in more users, so I can see that local scrollback now becomes more valuable for users who aren't accustomed to using screen/tmux...

[ViViDboarder]

@dwiel that's a good point...

That said, it could be an option. On my phone I'd probably not be using applications like that and scrolling would be more useful since the screen is small. On my desktop I'd turn off size spoofing and just use Tmux.

[dwiel]

yeah for sure, if its an easy option that helps in some cases, and someone is willing to implement it, why not

On Thu, Feb 6, 2014 at 11:35 AM, Ian notifications@github.com wrote:

@dwiel https://github.com/dwiel that's a good point...

That said, it could be an option. On my phone I'd probably not be using applications like that and scrolling would be more useful since the screen is small. On my desktop I'd turn off size spoofing and just use Tmux.

Reply to this email directly or view it on GitHubhttps://github.com/keithw/mosh/issues/122#issuecomment-34341938 .

[Spaceghost]

If only there were ample options for diverting output and paging text in unix-like operating systems!

[acook]

This is an anti-feature. You should be using tmux or screen anyway. If you think that using mosh should obliviate your need for a screen multiplexer then you do not understand the purpose of any of these tools, please just use autossh it will most likely do everything the way you expect.

[neolee]

In case someone may have not known, a while ago Mosh team released an interesting document named 'Mosh 2014 Ideas list', in which they described their design to solve the scrollback issue. I pretty much like the solution (something like a very mini part of tmux, just to scrollback) and I think that is the right direction. Now just wait some great contributors to implement it.

This IS a feature by the way.

[nicowilliams]

Yes, a minimal local screen/tmux just for scrollback seems like the right approach.

[hartzell]

It sounds as if different users come to Mosh for different reasons, trying to satisfy different itches.

@andersk (and others since)

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 (emphasis hartzell's), you might as well just use SSH.

I don't want those Mosh features, but that's not all that Mosh brings to the table.

I frequently wander at work (a multi-building campus spanning a small city) and in the evening I close my laptop and lock it in a drawer (or take it home). When I do work from home I have a reasonable (not FIOS) broadband connection through a VPN and latency isn't that bad). I don't do serious work on my iOS devices and I don't try to ssh into remote systems on BART or the bus or the ski lift.

It is revolutionary, mind blowing, and totally enabling to be able to flip open the laptop and pick up where I left off. No lost context, things that were going are still going, etc....

Autossh doesn't seem to give me persistent connections, so it doesn't help me (reconnecting is easy, the lost context is the part that makes me sad). Maybe there's an ssh configuration that would give me what I need, suggestions and pointers would be welcome. the roaming seems to be particularly problematic.

Screen and tmux are both trying to do a couple of things: helping me maintain all of my work in progress given intermittent connectivity and providing a simplistic windowing system.

That windowing system isn't interesting to me; I know that some people use tmux to free themselves from the tyranny of the mouse but if tmux weren't maintaining my session for me I'd never give it another look. I don't want to cram my work into a set of tiled ascii windows.

So far the best system I've found uses tmux and iTerm's built in integration. It's far from seamless though.

None of those tools give me the persistent session management and roaming that Mosh offers and I want it. I don't think that I have any particular right to have it, and I certainly don't think that the Mosh developers owe it to me, but it would be really useful.

I'd love to see a Mosh that got completely out of the terminal emulator business, one that used all of it's magic to maintain a synchronized image of the byte stream using unprivileged components. Either side would be free to throw away anything that both agree has been synched so there wouldn't be that much garbage hanging around, predictive typeahead could still be useful when things were slow (if it's still feasible), and native scrollback would work. And persistent connections. yay. I could reconnect and what ever was written out to my screen would be there waiting for me, ready to scroll back and read as required.

For my use case, calling the control-c thing a Mosh feature is almost disingenuous: if I were being sassy I'd say that they've chosen to model a terminal screen to show off their diff-based approach and it has the side-effect that if you mistakenly generate a bunch of output you can kill it with a control-c. That doesn't solve a problem that I actually have (see below) and unfortunately when I do intentionally generate output, I'm SOL.

Not everybody has your^H^H^H^Hmy use case. But not everyone has mine^H^H^H^Hyours either.

g.

[andersk]

@hartzell, it’s not that your desires are invalid (for the most part, although predictive typeahead cannot work without Mosh having full control over the terminal state). But surely you understand that we can’t just abandon all these features that our existing users rely on in order to satisfy your new use case. What you’re describing is so different from Mosh that it would probably end up being a separate software package, so it isn’t really relevant to this issue. And either way, the code isn’t going to write itself.

Let’s try to keep this issue on topic, please. As we’ve said before, the developers are absolutely interested in a scrollback feature; we don’t need to have arguments about that. What we need is either enough spare time to sit down and implement it, or a well-designed pull request from an outside contributor.

[hartzell]

I appreciate the effort that all y'all are putting into Mosh and don't mean to distract.

Just wanted to highlight that Mosh represents several really useful advances.

I'd be curious how many people think Mosh's killer-est feature is being able to work on Caltrain and how many think it's being able to pick up where they left off. Unfortunately one seems to get in the way of a bomber implementation of the other.

I'm not asking for a poll though, Mosh has what it has, it's clearly a big win for its community and you have a plan to make it better. That rocks.

[nicowilliams]

I find the type ahead prediction lovely but disturbing too: really, you can't predict what my $EDITOR will do, so why try? I'd settle for a status line showing as-yet unacknowledged keystrokes. Of course, there's still the redraw-by-diffs business, so mosh can't get entirely out of the terminal emulation business.

Nico

[andersk]

We’re still way off topic here (did you know we have an IRC channel, #mosh on Freenode? It’s true!), but:

• I think there’s plenty of room for Mosh to become a great solution for all these use cases, especially in a future where we can get integration with local terminal clients (although that’s very hypothetical for now).
• Mosh is surprisingly good at predicting what $EDITOR will do, at least when you’re typing text rather than running commands, and it shuts prediction off when it notices it’s started being wrong. If it’s working poorly, feel free to report bugs.
• If you’re just not a fan of prediction, we do have mosh -n (mosh --predict=never) to turn it off; see the man page for other options.
• Without being in the terminal emulation business, Mosh basically couldn’t draw anything extra, because it needs to be able to undo it later.

[FiloSottile]

Still OT, sorry, but I struggled with issues similar to the people in this thread that I've been following hoping for a solution. So here is mine: it has permanent sessions, native scrollback, and all the mosh benefits.

http://filippo.io/my-remote-shell-session-setup/

[hadifarnoud]

not sure why this issue was closed. is this solved?

[MichaelSp]

Here is my +1 if this makes any difference....

[The-Compiler]

Someone contributing code would probably make a difference :wink:

But to be honest, I don't see the point of implementing this in mosh - if you want native client-side scrolling you might (as it's been said) basically just use ssh/autossh/screen or tmux to get (nearly) the same behavior.

If you want server-side scrolling, you can already have it today by using screen/tmux on the server, so I don't think it makes sense to duplicate that feature in mosh.