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.

[hgbork]

Within xfce4-terminal a mosh user@example.com --no-init keeps scrolling as it is and I see everything, even the output I had before invoking mosh.

But yes, this works only if the output is generated line by line and not in a huge chunk; e.g. (quite useless command) while read l; do echo "$l"; sleep 0.01; done < <(ls -alsR /etc)

For me this works fine and if commands produce big chunks of text in short time (and mosh cut them), I can either pipe to $PAGER or send it to a file.

[ThomasSteinbach]

Mhh :/ Hope it will ever be implemented

+1

[scottj97]

My understanding is that mosh starts dropping output when it sees that the client end can't keep up. That results in an incomplete native scroll buffer on the client end.

Could it be as simple as adding a flag to disable this output dropping feature? --no-drop?

[andersk]

@scottj97 No. There’s no block of code somewhere that implements an “output dropping feature” to be disabled. Output dropping is an emergent property of the Mosh design and protocol. Enabling reliable scrollback will require substantial changes to both.

[fawaf]

very much +1

[briner]

I'd love to have this feature. I'll be ready to pay for that. Why not create a bounty for it ?

[jordanade]

It sounds like most would be happy without "complete native scrollback" but rather, say, 3x or some configurable ratio of the current screen's height. But it sounds like mosh couldn't do this without communicating the false 3x height to apps like vi and emacs, thus ruining their full-screen UI. There's no way to tell the server that the screen is 24 rows while actually syncing 72 rows. Is that right?

[cgull]

Correct. The emulated terminal's window size must be the same as that displayed for full screen apps to work well. The way scroll back is usually implemented is that an emulator maintains a separate buffer of rows for scroll back. When cursor motion pushes text off the window it's copied into the scroll back buffer. So the size doesn't matter much for implementation.

But on Mosh, we have to do that on the server side and then find some way to display it on client, either in band from the remote server (but screen/tmux do this well already) or out of band, on the local client, with an extension to the protocol (big task, and it still wouldn't get native-like scroll back in your outer GUI terminal emulator). It's not an easy/trivial issue to solve.

[gvaish]

Though not really a perfect solution, but using screen helps me scrollback.

Using the default bindings for screen:

. Execute C-a Esc to enter into copy / block selection mode. . Use mouse scroll, up/down or C-b/C-f to scroll.

[MisterTea]

If you are willing to sacrifice type prediction, you can use Eternal Terminal. ET keeps your connection alive and supports native scrollback: https://mistertea.github.io/EternalTCP/

[ezyang]

https://github.com/4ast/mosh/commit/b642df68efe1b437ceeb6ccb2d7369b4f9518fd6 may be of interest

[rerime]

Mrrr.....Hope it will ever be implemented +100500

[sterpe]

Guessing this is still not resolved...

[roosemberth]

+1, I think people would even like a bounty for this

[danielmotaleite]

how about having a mosh option to automatically start screen or tmux... this would allow both the mosh features and the screen/tmux scrollback!

I think most people really miss the scrollback, but always forget to start screen or tmux ... if mosh could do that automatically, the problem is solved

[t-nelson]

@danielmotaleite mosh doesn't need to support that. You can do it yourself. I've achieved the same for years with the following for in ~/.profile

if [[ "$SSH_TTY" != "" ]]
then
  if [[ "$TERM" != "screen" ]]; then
    screen -dr default
    if (($?)); then
      screen -ln -S default
    fi
  fi
fi

[calder]

+large-number. This is a dealbreaker.

[cpakkala]

I appreciate all the hard work on mosh, but the "workaround" is simply not good enough. No one has mentioned it, but I find it hard to believe that I'm the only one whose use-case is as follows:

Start a single tmux session on one host, per activity ("session" and "activity" to me are synonymous), and then use mosh within various tmux panes to remote into other machines. This is much cleaner and more organized than moshing into each machine and then starting a tmux session on each one. More importantly doing the latter breaks the abstraction of an "activity" for me; yet the former is problematic because then I either have to deal with the missing scrollback in each of the mosh panes, or I have to nest a tmux session in each pane. Nesting, of course causes many larger issues and is to be avoided...

[ddacunha]

I believe I have read most of the 67 previous comment I appreciate this issue is still open so that mosh can gracefully manage packet loss handling and have an always working Control-C. However I have not seen the following proposal: could I choose how many lines mosh actually returns to my terminal upon completion of the command? Or is that not possible without the terminal app allowing to change the terminal history?

[rledisez]

I rebased patch from @4ast on v1.3.2 (see last two commits on https://github.com/rledisez/mosh/commits/localScrollback-1.3.2)

@andersk if I take time to make it an option that must be enabled on the client side, would this be something that could be accepted eventually?

At this point, I'm just asking if it is worth I spend time on it (if yes, i take any advices ;))

[noaho]

@rledisez even if you have to fork mosh, you will still have users. I can't use eternalTCP because I need UDP support.

[ghost]

+1 scrollback

[crushcafeteria]

please give us scrollback. pleaseeeeee.....

[Sora233]

+1

[Jan69]

I can't believe this has dragged on for 6 years, at this point, and still nowhere near the answer.... also, unrelated to this specific issue, but there's no way to even just disable all of the history-stuff? why not?

[tomas]

@rledisez does scrollback work in your branch? if there's anything missing just point me in the right direction and I'll try to get it working.

[shovas]

+1 Scrollback needed. Screen or tmux are effective, I imagine, but I don't think I'd make the switch without this being native. I just don't like have to run extra programs every time I login. I have too many sessions for that.

[KopfKrieg]

I have too many sessions for that.

How about one tmux session per machine? You can create new "windows" within tmux, or split the view.

[tomas]

I'm trying out @rledisez's branch and, although type prediction isn't available, native scrollback works beautifully.

[abhatia2107]

@rledisez As it looks like native scrollback is working in your branch. Can we expect it to come in master branch?

[NyaMisty]

Why there aren't any feedback from the maintainers? This issue has been opened for almost 6.5 years, and someone has made a patch. Whether merge it or not, plz give us some response ;) I'm hoping this will be resolve before its 7th anniversary.

[LvChengbin]

+The weight of the world.

To use tmux together with mosh can solve this problem by adding set -g mouse on in .tmux.conf file.

[AndrewSav]

I'm hoping this will be resolve before its 7th anniversary.

Nope. And by the looks of it one should not hold their breath even for 10th.

[notmike-5]

sad

[dandv]

For those who want autossh + mosh + native scrolling, there's Eternal Terminal.

mosh is a great idea, but I need the scrollback buffer a lot more than I need local echo, so I'm very happy with ET.

[sumikum7]

Is this still not supported? I have recently started using this combination: mosh + iterm + tmux. Can I attain a native scrolling feature by doing some magic within their configurations?

[eminence]

Correct, mosh does not have any ability to manage a local scrollback buffer. Your best option remains to use tmux or screen on the remote system. Some options (like setting mouse on in tmux) will let you use your mouse wheel to automatically scroll the tmux buffer.

[zhouzach]

@eminence I use tmux on mac, but can not attain a native scrolling feature.why?

[dandv]

Your best option remains to use tmux or screen on the remote system.

Another option is to use Eternal Terminal. It manages the local scrollback buffer very well.

/unsubscribe

[notmike-5]

Soylent green is people

[axeII]

Eight years later....

Umm any update on this 🙏? This is really one of the feature I am missing on mosh 😞.

[RipperSK]

I was looking into using Mosh. I have it installed and tested for the most part, but this is a show stopper for me 😞

Is there a way to get this feature implemented ?

[sumikum7]

Is this still not supported? I have recently started using this combination: mosh + iterm + tmux. Can I attain a native scrolling feature by doing some magic within their configurations?

I am able to scroll somehow by using tmux with few extra configs in ~/.tmux.conf. It's already mentioned above by other users. Recommend others to follow the suit if possible.

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

[Kabouik]

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

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

[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

[AndrewSav]

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.

What does this workaround achieve then?

[andersk]

@AndrewSav Your question has been addressed in earlier comments. (I don’t mean to be rude—it’s just the more we repeat the previous discussion, the harder it gets to read the previous discussion.)

[AndrewSav]

@andersk I read that now but that comment does not seem to be related to the workarond. Also it seems to be way up before the workaround was posted, which also hints it could be unrelated. What am I missing?

[Khalian]

A much simpler alternative to mosh would be https://www.harding.motd.ca/autossh/

Combine that with tmux/screen/byobu and its a lot less hassle to maintain. No extra servers to install on the service machine either, just plain old ssh.