Mosh: Scrollback und alternativer Bildschirm (vorher: Use alternative screen on smcup/rmcup )

Oder vielleicht sollte der Client das reale Terminal immer in den alternativen Bildschirmmodus versetzen, und zwar aus dem gleichen Grund wie Fluchanwendungen – der Scrollback-Verlauf, den es auf dem primären Bildschirm erzeugt, ist sowieso nicht besonders nützlich.

Bei normaler Verwendung (wie zeilenweises Tippen auf der Shell) wird das Scrollback am realen Terminal etwas nützlich sein. Ich bin mir nicht sicher, ob ich das ganz aufgeben möchte, obwohl es den Benutzer vielleicht ärgern würde, dass größere Drucke nur teilweise im Scrollback vorhanden sind.

Hi, ich würde gerne wissen, ob Sie irgendwelche Pläne zu diesem Thema haben? Ich denke, Mosh sollte genau wie ssh funktionieren, dass es in den smcup-Modus wechselt, wenn die Remote-Anwendung dies anfordert. Ich finde es ziemlich nervig, wenn ich mit vim eine große Datei öffne und es viele Scrollbacks hinterlässt.

Hier der aktuelle Lösungsvorschlag:

(a) mosh-client versetzt das Terminal für die ganze Zeit in den alternativen Bildschirm

(b) Der Mosh-Server interpretiert SMCUP/RMCUP so, wie es xterm tut, sodass das "vim" der Leute weiterhin genauso funktioniert wie in xterm (oder im Bildschirm mit aktiviertem Altscreen).

(c) wir schnappen uns Control-Bild-Auf und Control-Bild-Ab für unsere eigenen hinterhältigen Zwecke (um ein ordentliches Zurückblättern zu ermöglichen).

Klingt für mich vernünftig. Ich habe die folgenden Änderungen an (c) vorgeschlagen:

• wir greifen auch Ctrl-Up und Ctrl-Down (da dies das Ctrl-Wheel im Gnome-Terminal sendet)
• aber wir greifen keine Tasten zum Zurückscrollen, während sich die innere Anwendung in einem alternativen Bildschirm befindet.

Verstehe ich richtig, dass der Plan hier darin besteht, ein Scrollback ähnlich dem bereitzustellen, was ein normales Terminal bietet? Das heißt, wenn ich einen Befehl mit viel Ausgabe ausführe, kann ich zuverlässig mit den Bildlaufleisten meines Terminals zurückscrollen, um alles zu sehen, was von diesem Befehl ausgegeben wurde? Das ist für mich ein sehr wichtiges Usability-Thema. Danke!

Ja, Scott, das ist der Plan, obwohl Sie die Bildlaufleisten Ihres lokalen Terminals nicht verwenden können. Im Moment können Sie screen oder tmux auf der Serverseite verwenden, um diese Funktion zu erhalten.

Das ist eine coole Idee. Ist es möglich, auch das Mausrad zu unterstützen?

Ja, wenn wir es mit Anders' Änderung machen, wird es das Mausrad unterstützen.

Einverstanden. Dies ist im Moment das einzige signifikante Problem mit Mosh. Es ist das einzige Problem, das meine Erfahrung beeinträchtigt hat.

+1

+1

Ich stimme zu. Ich würde viel lieber eine ganze Seite PGP-Müll lesen :)

Ich stimme zu. Ich würde viel lieber eine ganze Seite PGP-Müll lesen :)

+1

(Ich ... konnte einfach nicht widerstehen ...)

+1 dazu

+1 für das Beheben des Scrollbacks in Mosh (Showstopper für mich)

-2 Mkaysi

+1, ich habe manchmal cat eine Datei auf den Server kopiert, um sie lokal zu kopieren, und das Zurückscrollen wird nicht unterstützt, was dies verhindert.

+1 zum Beheben des Scrollbacks (das bisher einzige wirkliche Problem mit Mosh).

+1 zum Beheben des Scrollbacks, -1 für mkaysi, ich frage mich, warum Mosh sich dabei nicht einfach wie ssh verhalten kann. Ich habe riesige Verzeichnisse, in denen ich den ganzen Tag "ls" habe, also muss ich ssh verwenden.

Wie die sichere SSH-Shell, ermöglicht jedoch Mobilität und ist reaktionsschneller und robuster.

@ubershmekel : Sie könnten screen oder tmux auf der Remote-Seite zum Zurückscrollen verwenden. Oder einfach ls | less .

Ich frage mich, warum sich Mosh hier nicht einfach wie ssh verhalten kann.

Ich bin froh, dass du gefragt hast. :)

SSH übermittelt einfach einen Strom von Bytes vom Server zum Client; es ist egal, was die Bytes darstellen. Das lokale Terminal (XTerm oder was auch immer) bekommt also den gesamten Verlauf in Ordnung und kann scrollen.

Im Gegensatz dazu verfolgt Mosh den _aktuellen_ Zustand des Terminals auf der _Server-Seite und synchronisiert dann diese Darstellung zwischen Client und Server. Dies ist die wichtigste Designentscheidung, die die einzigartigen Funktionen von Mosh ermöglicht – Roaming, lokales Echo und bessere Ausnutzung schlechter Verbindungen. Auf der anderen Seite verkompliziert es einige Dinge, die in der SSH-Welt des geordneten Transports von Bytes einfach sind.

Um das Scrollback zu unterstützen, müssen wir diesem Terminalstatusobjekt einen Verlauf hinzufügen und das Protokoll erweitern, damit der Client bei Bedarf Teile des Verlaufs anfordern kann, während der Benutzer scrollt. (Ohne dies bei Bedarf zu tun, verlieren wir einen entscheidenden Vorteil von Mosh gegenüber SSH, nämlich dass Befehle, die Ausgaben spucken, mit einer festen „Framerate“ aktualisiert werden, anstatt die Verbindung zu verzögern.)

Dies ist sicherlich machbar und ist offensichtlich etwas, was viele Leute wollen. Aber es ist nicht wirklich "einfach dasselbe wie SSH zu tun" und es ist keine triviale Änderung. In der Zwischenzeit denke ich, dass das Ausführen screen oder tmux auf der Serverseite eine gute Problemumgehung ist (und viele andere Vorteile hat).

Ich muss sagen, dass das Ausführen screen auf dem Server genau das war, was ich mit Mosh vermeiden wollte. Das habe ich mit SSH gemacht, als ich befürchtete, dass die Verbindung aufgrund einer IP-Änderung oder so etwas unterbrochen wird. Bei Mosh hatte ich gehofft, dass ich es einfach laufen lassen könnte und alles andere automatisch erledigt würde.

Sie könnten vielleicht sogar Mosh mit Bildschirm integrieren. :-)

@kmcallister

Ich frage mich, ob Mosh einen alternativen Modus entwickeln könnte, in dem es die ganze pty-Magie überspringt und sich einfach wie normales ssh verhält.

Dies würde natürlich den Vorteil der Latenzoptimierung zunichte machen, aber ich glaube, viele Leute (zumindest ich selbst) interessieren sich sowieso nur für die Verbindungspersistenz. In diesem Modus würde eine Anzeige wiederhergestellt, indem einfach die letzten n Bytes bedingungslos wiedergegeben werden. Das Nachverfolgen der lokalen/entfernten Puffer-Offsets, um die richtige Menge an Wiedergabe zur richtigen Zeit auszulösen, sollte dann eigentlich ziemlich einfach sein ...

Bei Mosh hatte ich gehofft, dass ich es einfach laufen lassen könnte und alles andere automatisch erledigt würde.

Du kannst rennen

mosh user<strong i="8">@host</strong> -- screen -dR

Das hilft auch bei einem anderen Problem. Wenn ein mosh-client unerwartet stirbt (z. B. weil der Client-Rechner die Stromversorgung verloren hat), bleibt der entsprechende mosh-server nutzlos herum. Aber das Ausführen screen -dR wird dazu führen, dass der andere screen Prozess beendet wird, wodurch dieser alte mosh-server wird. Sie können dies natürlich mit benannten screen -Sitzungen und dergleichen ausgefeilter gestalten.

@moe: Was Sie beschreiben, ist machbar, aber ich zögere, Mosh alternative Modi hinzuzufügen, die das Funktionsprinzip grundlegend ändern. Vielleicht würde so etwas wie autossh Ihren Anforderungen entsprechen?

Ich habe versucht, Mosh für die Verbindungspersistenz zu verwenden, und nichts, was ich vor der Verwendung gelesen habe, gab mir einen klaren Hinweis darauf, dass es alles andere als eine gewöhnliche Shell mit einem verbesserten Transport war. Als Mosh einige wichtige Ausgaben verwarf, hatte ich keine Ahnung, was los war, und ich verschwendete ein paar Tage (Kalenderzeit, mehrere Stunden tatsächliche Fehlerbehebungszeit) damit, alles andere zu betrachten, weil mir nicht einfiel, dass ein Tool für dauerhafte Verbindungen und Eine bessere Latenz würde auch meine Daten wegwerfen. Danach kann ich Ihnen nicht mehr vertrauen, nicht weil die Art und Weise, wie Mosh arbeitet, unvernünftig ist, sondern weil die Art und Weise, wie es beschrieben wird, nicht ausdrückt, dass Sie nicht damit rechnen können, die vollständige Ausgabe eines Befehls zu erhalten. (Ich vermute, es vermittelt auch nicht die Ziele, die zu der Entscheidung geführt haben, dass es so funktioniert, aber das ist nicht wichtig.) Zumindest sollten die Bedingungen für das Verwerfen von Daten eine herausragende Position erhalten, wo kein neuer Benutzer etwas liest über Mosh konnte es vernünftigerweise nicht übersehen. Wenn ich einen solchen Hinweis gelesen hätte, bevor meine Ausgabe verloren gegangen wäre, hätte ich diese Tage der Verärgerung mit einem Moment des "Oh, das hat das gemeint!" eingetauscht, selbst wenn ich die Warnung nicht verstanden hätte!

Ich kann Polyergic nicht zustimmen. Ich denke, die Seite ist gut gemacht und auch die Schnittstelle mit den unterstrichenen Zeichen sagt gut aus, dass einige Vorhersagen gemacht werden. Ich hatte keine Probleme, nicht zu verstehen, was passiert. Das einzige, was mich überraschte, war, dass --predict=never die Ausgabe immer noch nicht zum Laufen brachte, da ich es gewohnt war.

Also würde ich vielleicht einfach auf einen Schalter drängen (ich kann dann bash-alias), der alles übertragen würde. Es kann immer noch vorhersagen.

Also ich sehe hier drei Möglichkeiten:

• Vorhersage + nicht alles übertragen (nützlich für Verbindungen mit hoher Latenz und geringer Bandbreite)
• Vorhersage + alles übertragen (nützlich für Verbindungen mit hoher Latenz und hoher Bandbreite)
• keine Vorhersage + nicht alles übertragen (nützlich nur für Verbindungspersistenz)

Ich falle in die 2. Kategorie. Transatlantische Verbindungen nach Europa haben eine Latenz von 100 ms, sind aber schnell. Ich würde in diesem Fall Mosh in Tash umbenennen: Transatlantic Shell. :-)

@kmcallister

Emulieren eines Terminals (Bildschirm) innerhalb eines emulierten Terminals (Mosh), in der Reihenfolge
native Funktionalität (Scrollback) des einschließenden Terminal-Emulators zu emulieren
(xterm, iterm) führt nicht und kann nicht zu einer akzeptablen Benutzererfahrung führen.

Das ist das grundlegende Problem hier. Mosh ist natürlich auch nicht schuld
30 Jahre Stagnation im Terminal-Emulator-Geschäft, noch kann es sauber werden
Lösen Sie die Situation von dort aus, wo sie sich gerade im Stapel befindet.

Daher mein Vorschlag eines 'dummen Modus', als kurzfristiges Pflaster
für die nächsten Jahrzehnte.

@mitar , ich sehe keinen Widerspruch zwischen dem, was ich gesagt habe, und dem, was du gesagt hast; Um die Dinge kurz zu wiederholen, was ich sehe, ist Folgendes:

Ich sagte: Mosh verliert Daten auf unerwartete Weise; Beschreibungen von Mosh sollten Erwartungen setzen, die seinem Verhalten entsprechen.

Sie sagten: Die Mosh-Website ist nett; die Vorhersageindikatoren sind nett; Eine Option, alles zu übertragen, wäre schön.

Was vermisse ich? Haben Sie irgendwo einen deutlichen Hinweis gesehen, dass Mosh nicht die gesamte Ausgabe Ihrer Befehle behält?

@moe

Das Emulieren eines Terminals (Bildschirm) innerhalb eines emulierten Terminals (Mosh), um die native Funktionalität (Scrollback) des einschließenden Terminal-Emulators (xterm, iterm) zu emulieren, führt und kann möglicherweise nicht zu einer akzeptablen Benutzererfahrung führen.

Nun, könnten Sie beschreiben, was an der Benutzererfahrung inakzeptabel ist? Das wären nützliche Informationen für uns.

Im Allgemeinen ist die Welt der Computer voll von scheinbar lächerlichen Verschachtelungs- und Emulationsebenen, die dennoch eine perfekte Benutzererfahrung bieten.

@kmcallister

Vor allem unterstützt der Frankenstack kein natives Scrollen. Das ist ein Showstopper.
„Copy-Mode“ und virtuelle Scrolling-Hacks sind kein Ersatz. Es gibt auch eine Fülle von subtileren
Probleme, aber Sie (als Autor eines Terminal-Emulators) brauchen mich nicht, um Ihnen davon zu erzählen. ;)

Wie gesagt, ich mache Mosh nicht für die lächerliche Terminal-Situation von heute verantwortlich – das war schlimm
schon lange bevor es mosh überhaupt gab. Angesichts des Projektumfangs hatte Mosh kaum eine andere Wahl
als sich wie alle anderen auf die Schultern von Gnomen zu hocken, und dafür steht es gar nicht so schlecht.

Ich sage nur, dass Mosh mit dem vermeintlichen 'dummen' Modus für diejenigen von uns funktionieren könnte, die es getan haben
keine Latenzprobleme und wer die Persistenz gerne hätte, aber einen kaputten Scrollback nicht vertragen kann.

Ein Pflaster auf dem Pflaster sozusagen.

Nur bis sich endlich jemand ein Herz fasst und die VT100-Terminalemulation komplett ablöst ...

Ich hätte auch gerne einen "dummen" Modus, mit dem ich in meinem Terminalfenster das normale Scrollback verwenden kann, um den Verlauf meiner vorherigen Aktionen anzuzeigen oder durch die Ausgabe eines großen Befehls zu scrollen.

Ich habe seit meinen BBS-Tagen keine vt100-Sachen mehr gemacht, also fühlen Sie sich frei, mich zu schlagen, aber könnten Sie nicht beides tun? Jedes Mal, wenn sich Ihr Bildschirmstatus so ändert, dass Sie eine Zeile nach oben vom Bildschirm wegscrollen müssen, könnten Sie nicht einfach nach unten gehen und ein cr/lf machen, die oberste Zeile vom Bildschirm wegscrollen und zurückscrollen, dann mit der Synchronisierung des Bildschirmstatus fortfahren, wie Sie es jetzt tun?

Natürlich könnten wir etwas Ausgabe verlieren, wenn wir offline gehen und Sachen von der Seite auf dem Server herunterscrollen, aber ich wäre damit einverstanden. Solange es funktioniert, während ich online bin und mit der Shell interagiere, wäre ich glücklich. Ich wäre sogar noch glücklicher, wenn Sie nachverfolgen würden, wann Dinge auf der Serverseite von oben gescrollt werden, die wir nicht gesehen haben, und eine Art Markierung wie "mosh: 60 Zeilen auf dem Server gescrollt, während Sie offline waren" herunterscrollen würden, aber das ist sicherlich im Gebiet der Bonusrunde. :-)

Um es klar zu sagen, ich drücke hier eine Präferenz aus. Wenn es schwierig ist und mit Ihren Zielen kollidiert, dann ist das auch in Ordnung. Ich werde trotzdem Mosh verwenden, weil das Stateless-Connection-Zeug meine Arbeitsweise wirklich ergänzt. :-) Danke, dass du das erstellt hast!

@timspencer Ich denke, was Sie vorschlagen, klingt vernünftig, ist aber möglicherweise nicht einfach zu implementieren. Mein Verständnis ist, dass Mosh den Bytestrom nicht verfolgt, sondern nur den aktuellen Zustand des Terminals betrachtet und einen Unterschied zum vorherigen Zustand berechnet und regelmäßig Aktualisierungen an den Client sendet. Wenn Sie cat /dev/urandom verwenden, wird der Bildschirm sehr schnell aktualisiert, aber Mosh sendet nicht _alles_ an den Client, sondern macht nur normale Schnappschüsse und sendet Diffs. Zumindest ist das mein Verständnis, ich habe den Quellcode nicht gelesen.

Abgesehen davon wäre es in der Tat großartig, einen Streaming-Modus zu haben, in dem Mosh einfach alles streamt und nur die Verbindung dauerhaft plus seine Vorhersagedinge macht.

Können wir das in zwei Themen aufteilen? Das von mir gemeldete Problem ist, dass Mosh das Terminal in den alternativen Bildschirmmodus versetzen sollte. Dies ist ein klarer Bugfix, den wir heute implementieren können. Es ist für die Mausrad-zu-Pfeiltasten-Emulation des Gnome-Terminals in Fluchanwendungen erforderlich. (Verwechseln Sie das nicht mit dem schickeren xterm-Mausereignisprotokoll, das niemand verwendet.)

Das zweite Problem, das aus diesem Thread hervorgegangen ist, ist, dass Mosh keinen nützlichen Scrollback-Verlauf unterstützt. Es ist wahr, dass ein Nebeneffekt des Versetzens des Terminals in den alternativen Bildschirmmodus darin bestehen würde, dass der nutzlose Scrollback-Verlauf von Mosh unzugänglich würde. Ich halte das für ein Feature, nicht für einen Bug. Wenn wir später viel Arbeit in die Entwicklung eines Systems stecken wollen, um nützliches Scrollback hinzuzufügen, wäre das großartig. Aber das ist eine völlig separate Feature-Anfrage, und sie ist nicht erforderlich für das, was ich als den üblichen Fall verstehe, in dem der Benutzer ohnehin nur screen innerhalb mosh ausführt. Ich schlage vor, dafür Nr. 122 wieder zu eröffnen.

Wir sollten Mosh jetzt reparieren, um das Terminal in den alternativen Bildschirmmodus zu versetzen, mit einem Befehlszeilenschalter, um ihn zu deaktivieren (wie less -X ), für Leute, die denken, dass ein defektes Scrollback wichtiger ist als ein funktionierendes Mausrad.

Anders, ok, ich bin davon für 1.2.4 überzeugt, wenn es nur bedeutet, smcup und rmcup zu Terminal::Emulator::open() und Terminal::Emulator::close() hinzuzufügen. Wären Sie bereit, einen Pull-Request einzureichen? (Ich nehme an, wir wollen, dass die eigentlichen Termininfo-Aufrufe in src/terminal/terminaldisplayinit.cc bleiben).

Ich halte die Mausrad-zu-Pfeiltasten-Emulation von gnome-terminal für einen schrecklichen Fehler. Es gibt viele Leute, die mir zustimmen: https://bugzilla.gnome.org/show_bug.cgi?id=518405

Leider sind die GNOME-Entwickler mit der Fehlerinterpretation nicht einverstanden, und anscheinend auch nicht andersk. Ich werde versuchen, Sie (vergeblich, vermute ich) davon zu überzeugen, dass es sich tatsächlich um einen schrecklichen Fehler handelt. Der Grund, warum die Zuordnung von Radereignissen zu Pfeiltasten schlecht ist, liegt darin, dass das Scrollen mit dem Mausrad eine _nicht-destruktive_ Operation sein soll. Mein mentales Modell des Mausrads ist, dass das Scrollen des Rads nur Ihre Ansicht des Terminal-Scroll-Puffers ändern soll. Es sollte niemals den Endzustand selbst ändern. Leider führt das GNOME-Verhalten der Emulation von Pfeiltasten in vielen Situationen, wie IRC-Clients und vielen anderen Szenarien, die im GNOME-Bugzilla-Thread erwähnt werden, tatsächlich zu einem dauerhaften Verlust des Eingangspufferstatus einer Anwendung, wenn das Mausrad angestoßen wird. Angenommen, ich bin gerade dabei, eine Zeile zu tippen, als ich das Mausrad betätige. Das Mausrad löst auf ärgerliche Weise einen Tastendruck auf der Tastatur aus, der die von mir eingegebene Zeile auslöscht. Die Behebung der einzelnen Anwendungen ist angesichts der Vielzahl von Anwendungen, die das Problem aufweisen, problematisch.

Die Tatsache, dass Mosh keinen alternativen Bildschirmmodus verwendet, war ein großer Segen für mich, weil es bedeutet, dass versehentliche Mausrad-Ereignisse den IRC-Client-Status nicht aus Mosh heraus zerstören. Da meine gesamte IRC-Client-Nutzung innerhalb von Mosh erfolgt, neutralisiert diese (unbeabsichtigte?) Funktion von Mosh den zugrunde liegenden GNOME-Fehler für mich vollständig. Ich wäre sehr traurig, wenn dieses Verhalten verschwinden würde.

Wenn Sie sich entscheiden, diese völlig verrückte Idee zu implementieren, stellen Sie bitte (wie andersk vorschlägt) einen Schalter bereit, um sie zu deaktivieren. Es ist nicht so, dass ich kaputtes Scrollback bevorzuge. Ich hasse Datenverlust vor allen anderen Überlegungen, und unerwünschte Pfeiltasten führen zu Datenverlust.

(In Bezug auf das zweite Problem in diesem Fehler, bei dem Mosh Datenverlust von Scrollback-Inhalten verursacht, unterstütze ich natürlich nachdrücklich alle Bemühungen, Mosh zu ändern, um Scrollback-Daten zu erhalten. Es gibt nichts Wichtigeres auf der Welt, als Datenverlust zu vermeiden.)

davidjao: gnome-terminal bietet bereits ein Kontrollkästchen (Bearbeiten → Profileinstellungen → Scrollen → Tastenanschläge verwenden, um auf alternativem Bildschirm zu scrollen), um die Pfeiltastenemulation vollständig zu deaktivieren. Aber niemand bestreitet, dass es genauso gut einen Befehlszeilenschalter für diejenigen geben könnte, die dies aus irgendeinem Grund pro Anwendung umgehen müssen.

Dieses Kontrollkästchen existiert nur auf Ubuntu und Derivaten von Ubuntu. Es ist nicht im Gnome-Terminal der Originalautoren enthalten, und andere Distributionen wie Fedora, Debian, Arch usw. bieten es nicht an. Natürlich können Sie es selbst flicken, aber das ist ein Schmerz.

Ich verstehe, dass wir uns alle einig sind, dass ein Befehlszeilenschalter wünschenswert ist, aber ich mache mir Sorgen, dass er ausgelassen oder als unwichtig angesehen werden könnte. Deshalb wollte ich kommentieren, warum es wichtig ist.

Vielen Dank an alle, die Option --no-init funktioniert perfekt, um den alternativen Bildschirmmodus für diejenigen von uns zu deaktivieren, die ihn nicht wollen.

Könnten wir, um die Dokumentation auf dem neuesten Stand zu halten, in der Manpage (im Abschnitt ENVIRONMENT VARIABLES) erwähnen, dass die Variable MOSH_NO_TERM_INIT smcup/rmcup hemmt?

Für mich löst die Option "--no-init" das Scrollback-Problem mit dem Mausrad nicht.

"--no-init" ist hier mit dem XFCE-Terminal völlig kaputt: Ein Teil der Ausgabe wird in der Historie vergessen und die Bildlaufleiste wird inkonsistent aktualisiert. Warum kann sich Mosh nicht einfach so verhalten wie ssh? Eigensinnig zu sein ist in Ordnung, aber es wäre auch schön, von den Netzwerkverbesserungen zu profitieren, ohne dass dem Benutzer unterschiedliche Terminalemulationsentscheidungen aufgezwungen werden.

Die

mosh user<strong i="6">@host</strong> -- screen -dR 

Problemumgehung funktioniert. Was wäre der entsprechende Befehl, um tmux anstelle von screen zu verwenden und sicherzustellen, dass keine tmux-Prozesse zurückbleiben, wenn ich die Verbindung trenne?

Danke.

Eigentlich habe ich zu früh gesprochen. Die Problemumgehung für den Bildschirm weist Probleme auf. Wenn ich es in zwei separaten Terminalfenstern nacheinander verwende, entführt das zweite Fenster den Bildschirm im ersten Fenster. Es wäre großartig, einen Scrollback zu haben, um dies zu beseitigen. Danke.

@dtenenba , dies ist kein Support-Forum für tmux und screen. Lesen Sie die Manpages ( tmux(1) , screen(1) ), insbesondere die Teile über die Option -d zu tmux attach-session und die -d , -r , -x Optionen bis screen .

Auf diesen Artikel möchte ich aufmerksam machen. Es beschreibt eine schöne einfache Einrichtung, die mosh und tmuc kombiniert, was zu einem funktionierenden Scrollback-Verlauf (mit Maus) auf Terminals führt, die xterm-Mäuse unterstützen. Unter OS X ist das iTerm oder sogar Terminal.app mit easySIMBL und dem MouseTerm- Plugin.

Es scheint, dass dies immer noch nicht wirklich implementiert ist? Das Ausführen mosh -n --no-init deaktiviert immer noch das Scrollen für mich? (Mac OS X mit Terminal.)

--no-init existiert nur, um das Verhalten vor 1.2.4 wiederherzustellen, bei dem die Bildlaufleiste des Terminals nicht deaktiviert wurde, um diejenigen zu beruhigen, die glaubten, dass die Funktionalität verloren ging. Mosh konnte nie garantieren, dass der Scroll-Puffer des Terminals tatsächlich mit irgendetwas gefüllt wird, geschweige denn mit irgendetwas Nützlichem, da es Frame-Deltas in seinem Statussynchronisierungsprotokoll optimiert. Siehe Nr. 122.

Es wäre wirklich schön, wenn Mosh Scrollback unterstützen würde. Ich verwende mysql auf dem Server und die Ausgabe von Describe ist länger als der Bildschirm, sodass ich den oberen Teil nicht sehen kann. Na ja, zurück zu ssh, denke ich.

In der mysql-cli können Sie einfach pager less tun und die Ausgabe wird zu less umgeleitet, anstatt direkt gedruckt zu werden.

@tsuna Danke! Dieser Befehl ist genial

Hoffnung, dass dies eines Tages behoben wird?

Das Flag --no-init funktioniert manchmal, manchmal nicht. Wir hoffen auf eine native Scrollback-Unterstützung mit Mosh.

Neueste iTerm2 auf macOS Sierra 10.12.5

Ja, das ist eine ziemlich große Sache für mich. Ich werde dies verwenden, sobald dieser offensichtliche Showstopper behoben ist.

Ich bin mir wirklich nicht sicher, worum es bei der ganzen Aufregung geht, wenn Sie Scrollback verwenden möchten, verwenden Sie screen oder tmux, sie sind wunderbare Tools, und wenn Sie sie richtig verwenden, können Sie so viel mehr tun, als zu versuchen, mehr Funktionen in Mosh zu packen. Die Unix-Philosophie für Werkzeuge, eine Sache gut zu machen, wird in diesem Fall PERFEKT veranschaulicht. https://en.wikipedia.org/wiki/Unix_philosophy

Ich habe dies gerade auf meinem lokalen Computer getestet, der eine Verbindung zu einem anderen Computer herstellt. Ich verbinde mich mit Mosh, verbinde mich wieder mit tmux mit -- tmux attach als Argument der Verbindungszeichenfolge, und ich werde wieder mit meiner Sitzung verbunden, mit der Möglichkeit, durch den Verlauf zurückzublättern, scrolle meine tmux "Fensterleiste", um zu gehen verschiedene Bereiche, kurz gesagt alles, wonach die Leute oben gefragt haben, OHNE irgendwelche Änderungen am Mosh.

Wenn Sie durch vorherige Befehle zurückscrollen, verwenden Sie wahrscheinlich nur Mosh oder Sie befinden sich im Bildschirm. Dies geschieht unabhängig davon, ob Sie sich über SSH oder Mosh verbinden, da es den "alternativen Bildschirm" selbst verwendet. Ich mag Bildschirm, aber tmux ist viel besser für mehrere Befehle und Sitzungen und handhabt das Scrollen und den Verlauf meiner Meinung nach viel vernünftiger.

@dragon788 gut das zu hören. Aber können Sie mit der Maus nach oben scrollen?
weil Sie erwähnt haben, dass Sie mit der "Fensterleiste" scrollen können, was ich
Denke hier kein Thema.

Am Samstag, den 21. Oktober 2017 um 6:26 Uhr schrieb dragon788 [email protected] :

Ich bin mir wirklich nicht sicher, worum es bei der ganzen Aufregung geht, wenn Sie Scrollback verwenden möchten
screen oder tmux, sie sind wunderbare Werkzeuge, und ihre angemessene Verwendung wird es tun
lassen Sie SO viel mehr tun, als zu versuchen, mehr Funktionen in Mosh zu packen. Das Unix
Die Philosophie für Werkzeuge, eine Sache gut zu machen, wird hier PERFEKT veranschaulicht
Fall. https://en.wikipedia.org/wiki/Unix_philosophy

Ich habe dies gerade auf meinem lokalen Computer getestet, der eine Verbindung zu einem anderen Computer herstellt. ich
Verbinden Sie sich mit Mosh, verbinden Sie sich erneut mit tmux mit --tmux Attach als
Argument der Verbindungszeichenfolge, und ich werde wieder mit meiner Sitzung verbunden
die möglichkeit zurück durch den verlauf zu scrollen, scrolle in meinem tmux "window bar" nach
Gehen Sie zu verschiedenen Fenstern, kurz alles, wonach die Leute gefragt haben
oben OHNE Änderungen an Mosh.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/mobile-shell/mosh/issues/2#issuecomment-338336608 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ABhWeSFAPBiXYl3BA5W4lb43V_fw2f_Lks5suR4HgaJpZM4ABSOa
.

>

Eduardo D. Bergavera jr.
Linux-Administrator
E-Mail: [email protected]
OpenID: https://launchpad.net/~edbergavera
Github: https://github.com/edbergavera

Die Aufregung hat nichts mit fehlender Scrollback-Funktionalität zu tun. Die Aufregung besteht darin, dass Mausradereignisse im alternativen Bildschirmmodus den aktuellen Befehlspuffer zerstören, da ein Mausradereignis als Pfeiltaste interpretiert wird. Dies ist verheerend, da versehentliches Scrollen zu Datenverlust führt.

Ihr Vorschlag scheint "GNU-Bildschirm nicht verwenden" zu sein, aber dieser Rat ist aus vielen offensichtlichen Gründen unhaltbar.

@edbergavera Ich scrolle zurück, indem ich den tmux-Verlauf über den Kopiermodus verwende (der die Befehlsausgabe auf der Fernbedienung beibehält, die IMO da ist, wo die Befehle ausgeführt werden und wo es wirklich darauf ankommt, wo der Verlauf sein sollte). Ich glaube, Sie können das Scrollrad der Maus verwenden, wenn Sie ein Plugin für tmux haben, das die Escape-Codes des Scrollrads als Signal interpretiert, um in den Kopiermodus zu wechseln und zu scrollen, oder Sie können einfach Präfix + [ oder was auch immer Sie binden, um in den Kopiermodus zu wechseln und dann Scrollen Sie mit Ihrer Maus, vorausgesetzt, Ihr Terminal erfasst die Ereignisse nicht und leitet sie intakt an den Server weiter. Präfix + Esc ist ein weiteres Äquivalent.

Was ist mit einem Flag, das angibt, wie viel Verlauf beim Start geladen werden soll (wie tail -n)?

Ich bin traurig, dass dies noch offen ist. Ich habe alle paar Jahre nachgesehen, ob die Unterstützung für natives Scrollen gelöst wurde, aber bis dahin kann ich dies leider nicht verwenden.

Zur Verdeutlichung: Ich interessiere mich nur für eine zuverlässige Wiederverbindung nach einem Netzwerkausfall, ohne dass Programme auf dem Remote-Host beendet werden.

Ich kann nicht glauben, dass das nie behoben wird :( Es ist ein Albtraum. ssh stirbt. mosh ist nicht verwendbar.

Mosh installiert, um es bei der Arbeit mit einer instabilen 4G-Verbindung zu verwenden. Sieht so aus, als ob es bei schlechten Verbindungen gut funktioniert, aber die fehlenden Bildlauffunktionen machen es für mich zu einem No-Go. Ich habe es sofort deinstalliert, da ich es vorziehe, mich ein paar Mal am Tag erneut bei SSH anzumelden, als diese wichtige Funktion zu verpassen.

@mr-propre Es ist wirklich eine grundlegende Tatsache der Benutzerfreundlichkeit. Ich verwende es, um eine Verbindung zu Spark-Clustern herzustellen, weil ssh fehlschlägt, und dann verwende ich Bildschirm mit STRG-A, Escape und dann Seite nach oben / unten, um zu scrollen, aber es ist höllisch irritierend und der Puffer ist zu klein.

Ich bin mir nicht sicher, ob es hier schon erwähnt wurde, aber wenn Sie von diesem Problem betroffen sind, sollten Sie sich alternativ Eternal Terminal ansehen.

Leute - ist Ihnen klar, dass Sie die Menge an Scrollback anpassen können, die Bildschirm und tmux speichern?

Dies ist ein gelöstes Problem für die meisten Leute (die serverseitig screen/tmux oder noch weniger verwenden). Mosh wird wahrscheinlich in absehbarer Zeit kein eigenes Remote-Scrollback-Protokoll bekommen.

Es ist mir bewusst. Es ist einfach scheiße, dass der Kunde das nicht wie jeden anderen handhabt
eine, von der ich je gehört habe.

Danke,
Russell Jurney @rjurney http://twitter.com/rjurney
Russell. [email protected] LI http://linkedin.com/in/russelljurney FB
http://facebook.com/jurneydatasyndrome.com

Am Dienstag, 13. August 2019 um 12:54 Uhr Keith Winstein [email protected]
schrieb:

Leute - Sie wissen, dass Sie die Menge des Zurückscrollens auf diesem Bildschirm anpassen können
und tmux speichern?

Dies ist ein gelöstes Problem für die meisten Leute (die screen/tmux verwenden, oder
noch weniger auf der Serverseite). Mosh bekommt wahrscheinlich kein eigenes
Remote-Scrollback-Protokoll in Kürze.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/mobile-shell/mosh/issues/2?email_source=notifications&email_token=AAAKJJKV4Y2R4PB2E6UWYL3QEMGPNA5CNFSM4AAFEONKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4GZK3I#issuecomment-5370 9,9170
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAAKJJMBSF2QEQUAEBR5X5TQEMGPNANCNFSM4AAFEONA
.

Dieses Problem ist wirklich ärgerlich - bis Sie lernen, tmux zu verwenden. Dann ist es kein Thema mehr.

Es tut mir leid, aber ich bin anderer Meinung. Aus meiner Sicht ist die Verwendung tmux ein bisschen wie ein Clog. Wenn ich tmux verwenden wollte, wäre ich gut genug mit ssh + tmux.

Eigentlich wäre ich neugierig, was der Vorteil von „mosh+tmux“ gegenüber „ssh+tmux“ ist?? Was die Leute denken?

Die meisten der gleichen Mosh-Vorteile gelten immer noch bei der Verwendung von tmux:

• Nahtlose Konnektivität, wenn Ihr Client das Netzwerk wechselt oder Ihr Client-Computer aus einem Suspend-/Ruhezustand kommt
• lokales Echo
• Besseres Control-C-Handling

Ich habe tmux und screen ausprobiert, aber sie beheben nicht das größte Problem, das ich mit Mosh habe: Ich kann keinen Python-Code in das Terminal einfügen. Ich mache ein separates Problem: https://github.com/mobile-shell/mosh/issues/1066

Ich selbst habe nichts gegen die Verwendung von tmux, aber das Scrollen mit tmux ist verzögert, da es erforderlich ist, darauf zu warten, dass der Remote-Server den aktualisierten Bildschirminhalt sendet. Eines der wichtigsten Verkaufsargumente von Mosh ist, dass es in langsamen oder unzuverlässigen Netzwerken eine bessere Interaktivität als ssh bietet. Wenn es jedoch um Scrollback geht, bietet das Verlassen auf tmux eine schlechtere Interaktivität als lokales Scrollback.

Wie schwer wäre es, Mosh mit einem Rollback zu versehen? Was gehört dazu?

Das Scrollen mit tmux ist jedoch verzögert, da darauf gewartet werden muss, dass der Remote-Server den aktualisierten Bildschirminhalt sendet

Wenn Mosh jemals lernt, wie man zurückscrollt, stelle ich mir vor, dass es dasselbe tun müsste, also verstehe ich diese Beschwerde nicht ganz.

Warum sollte es dasselbe tun? Im Prinzip sollte Mosh in der Lage sein, eine lokale Kopie des Scrollback-Puffers zu behalten. Ich nehme an, es könnte Probleme geben, wenn etwas das Terminal schnell genug spammt, dass der Client nicht den gesamten Text empfängt (da Mosh Bildschirmaktualisierungen absichtlich auf eine feste Framerate drosselt). Aber das ist lösbar; Mosh würde eine Art Algorithmus benötigen, um Scrollback-Inhalte mit dem Server zu synchronisieren, idealerweise mit einer niedrigeren Priorität als Bildschirmaktualisierungen.

Es ist 2020 und Ausgabe Nr. 2 ist noch offen ... oh Mann ...

Ich bin mir wirklich nicht sicher, worum es bei der ganzen Aufregung geht, wenn Sie Scrollback verwenden möchten, verwenden Sie screen oder tmux, sie sind wunderbare Tools, und wenn Sie sie richtig verwenden, können Sie so viel mehr tun, als zu versuchen, mehr Funktionen in Mosh zu packen. Die Unix-Philosophie für Werkzeuge, eine Sache gut zu machen, wird in diesem Fall PERFEKT veranschaulicht. https://en.wikipedia.org/wiki/Unix_philosophy

@dragon788 Wenn überhaupt, zeigt dies die Nachteile von _nicht_ der Unix-Philosophie zu folgen. Mosh bricht die Unix-Philosophie, indem es viel mehr als nur eine Sache tut, so dass es in der Position landet, in der es ein eigenständiger Terminalemulator ist, aber ein sehr eingeschränkter ohne Scrollback-Unterstützung.

Das ist für einen echten Terminalemulator in Ordnung (zum Teufel, ich benutze st und ich probiere andere Terminalemulatoren ohne Scrollback aus), aber wenn Mosh es tut, unterbricht es das bestehende Scrollback, was über das einfache Nichtunterstützen von Scrollback hinausgeht. Ich verwende bereits tmux , um die Mosh-Session unterzubringen, also warum sollte ich auch eine weitere tmux -Session auf der Serverseite starten?

Jetzt muss auf dem _Server_ (und das ist _jeder_ Server, mit dem Sie sich verbinden wollen) tmux oder ähnliches installiert sein, nur um Moshs _Breaking_ des Scrollbacks zu umgehen (nicht nur seine fehlende Unterstützung dafür), also wie folgt das? genau die Unix-Philosophie?

ssh setzt hier den Standard. Mosh verstößt gegen diesen Standard und erfordert das Hinzufügen einer völlig neuen Software, die die meisten Benutzer nicht auf dem Server haben möchten, sodass die Leute Mosh nicht annähernd so oft verwenden, wie sie es tun würden, wenn es das Scrollback so unterstützen würde, wie Benutzer es erwarten, weil Alternativen es unterstützen . Es gibt eine starke Haltung von „nicht mein Problem“, obwohl dies für die Mehrheit der Mosh-Benutzer ein sehr reales Problem ist, das den Einfluss der Arbeit der Mosh-Mitwirkenden auf das Projekt einschränkt. Offensichtlich geht es bei Open Source darum, Ihr Geld dort einzusetzen, wo Sie wollen, und hinzuzufügen, was Sie brauchen. Ich bin nicht in der Lage, diese Funktion hinzuzufügen, also verwenden ich und viele andere wie ich Mosh nicht, es sei denn, wir müssen es unbedingt tun. Ich hoffe, dass jemand auftaucht und diese Funktion hinzufügt, weil es eine große Lücke in Mosh als Open-Source-Projekt ist und seine Verfügbarkeit die Akzeptanz von Mosh dramatisch erhöhen und viele Benutzer sehr glücklich machen wird.

Die Art und Weise, wie Sie das Ticket geschlossen haben, bedeutet, dass niemand aufstehen und diesen Beitrag leisten wird, was bedauerlich ist. Das Mindeste, was Sie für Ihre Community tun können, ist, aufzuhören, den Schwarzen Peter weiterzugeben und die Unix-Philosophie zu missbrauchen, und einfach zuzugeben, dass Sie keine Lust haben, sie hinzuzufügen, und jemand anderen dies tun zu lassen. „Nicht mein Problem“ mag dazu führen, dass Sie sich besser fühlen, wenn Sie weniger offene Tickets haben, aber diese Einstellung untergräbt das Projekt und seine Benutzer. Dieses Ticket hat 76 Kommentare. Wie viele Ihrer anderen Tickets haben 76 Kommentare? Ich schlage vor, dass Sie darüber nachdenken, warum Sie zu Open Source beitragen und ob Sie Ihre Community mit dieser Einstellung überhaupt wertschätzen.

Bitte öffnen Sie dieses Ticket und lassen Sie zumindest jemand anderen vortreten und diese wichtige Funktion hinzufügen.

Ich bin mir wirklich nicht sicher, worum es bei der ganzen Aufregung geht, wenn Sie Scrollback verwenden möchten, verwenden Sie screen oder tmux, sie sind wunderbare Tools, und wenn Sie sie richtig verwenden, können Sie so viel mehr tun, als zu versuchen, mehr Funktionen in Mosh zu packen. Die Unix-Philosophie für Werkzeuge, eine Sache gut zu machen, wird in diesem Fall PERFEKT veranschaulicht. https://en.wikipedia.org/wiki/Unix_philosophy

@dragon788 Wenn überhaupt, zeigt dies die Nachteile von _nicht_ der Unix-Philosophie zu folgen. Mosh bricht die Unix-Philosophie, indem es viel mehr als nur eine Sache tut, so dass es in der Position landet, in der es ein eigenständiger Terminalemulator ist, aber ein sehr eingeschränkter ohne Scrollback-Unterstützung.

Das ist für einen echten Terminalemulator in Ordnung (zum Teufel, ich benutze st und ich probiere andere Terminalemulatoren ohne Scrollback aus), aber wenn Mosh es tut, unterbricht es das bestehende Scrollback, was über das einfache Nichtunterstützen von Scrollback hinausgeht. Ich verwende bereits tmux , um die Mosh-Session unterzubringen, also warum sollte ich auch eine weitere tmux -Session auf der Serverseite starten?

Jetzt muss auf dem _Server_ (und das ist _jeder_ Server, mit dem Sie sich verbinden wollen) tmux oder ähnliches installiert sein, nur um Moshs _Breaking_ des Scrollbacks zu umgehen (nicht nur seine fehlende Unterstützung dafür), also wie folgt das? genau die Unix-Philosophie?

Dies. So viel dazu.

Bringen wir dieses Gespräch aus der niedrigen Erdumlaufbahn zurück, Leute. Der Grund, warum Mosh kein Scrollback unterstützt, hat nichts mit Philosophie zu tun. Es hat auch nichts damit zu tun, ob dieses Ticket offen oder geschlossen ist – es ist bereits ein Ticket zum Zurückscrollen offen, und es ist nicht dieses Ticket, bei dem es um den alternativen Bildschirmmodus ging. Es hat alles mit begrenzter Entwicklerzeit zu tun. Wenn Sie das Mosh-Papier gelesen haben, werden Sie verstehen, wie die Art und Weise, wie Mosh Interaktivität priorisiert, die Bereitstellung eines verwendbaren Scrollbacks zu einer Herausforderung macht, so dass es bei der ursprünglichen Implementierung weggelassen wurde und seitdem niemand Zeit hatte, es hinzuzufügen. Wenn wir unendlich viel Zeit hätten, um an Mosh zu arbeiten, wäre eine Scrollback-Funktion wahrscheinlich eine Priorität. Niemand hindert Sie daran, diese Funktionalität zu entwickeln, wenn Sie daran interessiert sind, und wie immer wird eine gut gestaltete, gut implementierte Pull-Anfrage wahrscheinlich akzeptiert. Aber sich über ein abgeschlossenes Problem zu beschweren, wird das nicht schneller machen.

@andersk Ich denke, es ist diese Priorität der Interaktivität, die als Abweichung von der Unix-Philosophie angesehen wird. Mosh macht sowohl Verbindungen, die nicht sterben (ein Feature, das ich sehr gerne hätte) als auch Interaktivität (ein Feature, dessen Preis, ein Scrollback, der kein reiner vollständiger ASCII-Stream ist, ich nicht bereit bin zu zahlen). Was die Leute zu verlangen scheinen, ist die Zuverlässigkeit ohne die Interaktivität, da sie denken, dass der alternative Bildschirmmodus ein zu hoher Preis ist.

Pragmatisch interessiert mich nicht wirklich, ob Mosh der UNIX-Philosophie folgt oder nicht; Alles, was ich als Benutzer weiß, ist, dass es sich um ein großartiges Stück Software handelt, das man verwenden kann, abgesehen von diesem eklatanten Fehler.

Ich bin nicht hier, um den Autor zu bitten, das Feature kostenlos hinzuzufügen, ich verstehe, dass es das ist, was es ist, und mir wird weder Code noch Zeit oder Mühe oder irgendetwas geschuldet.

Mein Kommentar kritisierte _nur_ die Behauptung, dass (paraphrasierend) „Mosh das nicht tun sollte, weil es gegen die Unix-Philosophie verstößt“; Mein Gegenentwurf dazu ist, dass der ganze Grund, warum Mosh dies überhaupt tun muss, genau _weil_ es bereits gegen die Unix-Philosophie verstößt. Ich urteile nicht darüber, ob das gut oder schlecht ist, ich weiß nicht, was all die Kompromisse waren und was Mosh _nicht_ gekauft hat, wenn man der Unix-Philosophie folgt.

Meine Lösung in der Zwischenzeit ist, Mosh einfach nicht zu verwenden. Ich hoffe, dass ich in naher Zukunft in der Lage sein werde, ein Kopfgeld aufzusetzen, jetzt wo ich Mosh wieder kenne und weiß, was mir im Weg steht. Darüber hinaus werde ich einfach weiterhin SSH verwenden und den Autor respektvoll wissen lassen, dass dies das Einzige ist, was meiner Verwendung von Mosh im Wege steht (die Leute kümmern sich im Allgemeinen darum, dass einige Leute nicht von ihrer Arbeit profitieren, bis diese Leute unhöflich sind). .

@rjurney Ich bin mir ziemlich sicher, dass die Person, die die Unix-Philosophie zitiert, nicht der Autor ist. Es gibt keinen Grund, so scharf zu kritisieren.

Der Autor hat auch ein offenes Problem zum Scrollback . Es ist gesperrt, weil die Diskussion so gut wie vorbei ist. Wir alle wollen es, aber keiner von uns wird es haben, bis einige von uns es umsetzen. Aber das Thema ist offen. Es kommt jetzt auf uns alle an, nicht nur auf den Schöpfer.

Ich werde das offene Problem mit dem Scrollback freischalten, da es Gelegenheit hatte, sich abzukühlen. Vermeiden Sie es jedoch, dieses Problem (oder dieses Problem) zu kommentieren, wenn es nichts Neues hinzuzufügen gibt. Es gibt „Reaktions“-Schaltflächen in Github, mit denen Sie Ihr Interesse bekunden können (die nicht den gesamten Thread spammen), und Kommentare wie „+1“ sind nicht nützlich. Wir wissen, dass dies für einige Leute ein sehr wichtiges Problem ist und dass das Ausführen von screen/tmux auf dem Server nicht immer eine bequeme oder akzeptable Lösung ist.

Kommentare zur Unix-Philosophie sind interessant, aber definitiv __off-topic__ für diesen Github Issue Tracker. (Sie können sich jedoch gerne unserem #mosh-IRC-Kanal auf Freenode anschließen, um solche Dinge zu diskutieren).

Ich bin mir nicht sicher, ob es hier schon erwähnt wurde, aber wenn Sie von diesem Problem betroffen sind, sollten Sie sich alternativ Eternal Terminal ansehen.

Eternal Terminal hat kein Binärpaket für Centos 7, ich habe kürzlich Stunden damit verbracht, es manuell zu kompilieren und schließlich aufgegeben.