Mosh: Défilement arrière et écran alternatif (auparavant : Utiliser un écran alternatif sur smcup/rmcup )

Ou peut-être que le client devrait toujours mettre le vrai terminal en mode écran alternatif, pour la même raison que les applications curses - l'historique de défilement qu'il génère dans l'écran principal n'est de toute façon pas particulièrement utile.

En utilisation normale (comme la saisie ligne par ligne dans le shell), le défilement réel du terminal sera quelque peu utile. Je ne suis pas sûr de vouloir abandonner complètement cela, même si l'utilisateur serait peut-être ennuyé que des impressions plus grandes ne soient que partiellement présentes dans le défilement.

Salut, je voudrais savoir si vous avez un plan sur ce problème? Je pense que mosh devrait fonctionner comme ssh, qu'il entrera en mode smcup lorsque l'application distante le demandera. Je trouve cela assez ennuyeux lorsque j'utilise vim pour ouvrir un gros fichier et cela laisse beaucoup de défilements.

Voici la solution actuellement proposée :

(a) mosh-client place le terminal dans l'écran alternatif pendant tout le temps

(b) mosh-server interprète SMCUP/RMCUP de la même manière que xterm, de sorte que le "vim" des utilisateurs continue de fonctionner de la même manière que dans xterm (ou dans screen avec altscreen activé)

(c) nous saisissons control-pgUp et control-PgDown pour nos propres fins sournoises (fournissant un défilement correct).

Cela me semble raisonnable. J'ai proposé les modifications suivantes à (c):

• nous saisissons également Ctrl-Haut et Ctrl-Bas (puisque c'est ce que la molette Ctrl envoie dans gnome-terminal)
• mais nous ne saisissons aucune touche pour le défilement arrière lorsque l'application interne se trouve dans un écran alternatif.

Dois-je bien comprendre que le plan ici est de fournir un défilement semblable à celui fourni par un terminal ordinaire ? Autrement dit, si j'exécute une commande avec beaucoup de sortie, je peux revenir en arrière de manière fiable avec les barres de défilement de mon terminal pour voir tout ce qui a été produit par cette commande ? C'est un problème d'utilisabilité très important pour moi. Merci!

Oui, Scott, c'est le plan, même si vous ne pourrez pas utiliser les barres de défilement de votre terminal local. Pour l'instant, vous pouvez utiliser screen ou tmux côté serveur pour obtenir cette fonctionnalité.

C'est une bonne idée. Est-il également possible de prendre en charge la molette de la souris ?

Oui, si nous le faisons avec l'amendement d'Anders, il prendra en charge la molette de la souris.

D'accord. C'est le seul problème important avec Mosh pour le moment. C'est le seul problème qui a entaché mon expérience.

+1

+1

Je suis d'accord. Je préférerais de loin lire une page entière de déchets PGP :)

Je suis d'accord. Je préférerais de loin lire une page entière de déchets PGP :)

+1

(Je... juste... n'ai pas pu résister...)

+1 à ça

+1 pour la correction du défilement dans mosh (showstopper pour moi)

-2 Mkaysi

+1, je cat un fichier sur le serveur pour le copier localement et ne pas prendre en charge le défilement arrière l'empêche.

+1 pour la correction du défilement (le seul vrai problème avec mosh jusqu'à présent).

+1 pour corriger le défilement, -1 pour mkaysi, je me demande pourquoi mosh ne peut pas simplement se comporter comme ssh à ce sujet. J'ai d'énormes répertoires que je "ls" toute la journée donc je dois utiliser ssh.

Comme le shell sécurisé SSH, mais permet la mobilité et plus réactif et robuste.

@ubershmekel : Vous pouvez utiliser screen ou tmux du côté distant pour le défilement. Ou simplement ls | less .

Je me demande pourquoi mosh ne peut pas simplement se comporter comme ssh à ce sujet.

Je suis content que vous ayez demandé. :)

SSH transmet simplement un flux d'octets du serveur au client ; il ne se soucie pas de ce que les octets représentent. Ainsi, le terminal local (XTerm ou autre) récupère tout l'historique dans l'ordre et peut faire défiler.

En revanche, Mosh suit l'état _actuel_ du terminal côté _serveur_, puis synchronise cette représentation entre le client et le serveur. C'est la décision de conception clé qui active les fonctionnalités uniques de Mosh - itinérance, écho local et meilleure utilisation des mauvaises connexions. D'un autre côté, cela complique certaines choses qui sont simples dans le monde de SSH consistant à transporter les octets dans l'ordre.

Pour prendre en charge le défilement arrière, nous devrons ajouter un historique à cet objet d'état du terminal et augmenter le protocole afin que le client puisse demander des bits d'historique à la demande, au fur et à mesure que l'utilisateur défile. (Sans le faire à la demande, nous perdons un avantage clé de Mosh sur SSH, à savoir que les commandes qui génèrent une sortie seront mises à jour à un "framerate" fixe plutôt que de retarder la connexion.)

C'est certainement faisable, et c'est évidemment quelque chose que beaucoup de gens veulent. Mais ce n'est pas vraiment "faites simplement la même chose que SSH" et ce n'est pas un changement trivial. En attendant, je pense que l'exécution screen ou tmux côté serveur est une bonne solution de contournement (et présente de nombreux autres avantages).

Je dois dire que l'exécution screen sur le serveur était exactement ce que j'espérais éviter avec mosh. C'est ce que je faisais avec SSH quand j'avais peur que la connexion soit interrompue à cause d'un changement d'adresse IP ou autre. Avec mosh, j'espérais pouvoir l'exécuter et tout le reste serait pris en charge automatiquement.

Vous pourriez peut-être même intégrer mosh à l'écran. :-)

@kmcallister

Je me demande si mosh pourrait développer un mode alternatif où il ignore toute la magie pty et agit simplement comme ssh normal.

Cela supprimerait bien sûr l'avantage de l'optimisation de la latence, mais je pense que beaucoup de gens (du moins moi-même) ne s'intéressent de toute façon qu'à la persistance de la connexion. Dans ce mode, un affichage serait restauré simplement en lisant inconditionnellement les n derniers octets. Garder une trace des décalages de tampon local/distant afin de déclencher la bonne quantité de lecture au bon moment devrait en fait être assez facile alors...

Avec mosh, j'espérais pouvoir l'exécuter et tout le reste serait pris en charge automatiquement.

Tu peux courir

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

Cela aide également avec un autre problème. Si un mosh-client meurt de manière inattendue (par exemple, parce que la machine cliente a perdu de l'alimentation), le mosh-server correspondant traînera inutilement. Mais l'exécution screen -dR entraînera la fermeture de l'autre processus screen , tuant cet ancien mosh-server . Vous pouvez bien sûr rendre cela plus sophistiqué avec des sessions nommées screen et autres.

@moe: Ce que vous décrivez est faisable, mais j'hésite à ajouter des modes alternatifs à Mosh qui changent fondamentalement le principe de fonctionnement. Peut-être que quelque chose comme autossh répondrait à vos besoins ?

J'ai essayé d'utiliser Mosh pour la persistance de la connexion, et rien de ce que j'ai lu avant de l'utiliser ne m'a clairement indiqué qu'il s'agissait de tout sauf d'un shell ordinaire avec un transport amélioré. Lorsque Mosh a rejeté une sortie importante, je n'avais aucune idée de ce qui se passait et j'ai perdu quelques jours (temps calendaire, plusieurs heures de temps de dépannage réel) à regarder tout le reste car il ne m'est pas venu à l'esprit qu'un outil pour les connexions persistantes et une meilleure latence jetterait également mes données. Après cela, je ne peux pas vous faire confiance, non pas parce que la façon dont Mosh fonctionne est déraisonnable, mais parce que la façon dont il est décrit ne signifie pas que vous ne pouvez pas compter sur la réception de la sortie complète de n'importe quelle commande. (Je soupçonne qu'il ne parvient pas non plus à transmettre les objectifs qui ont motivé la décision de le faire fonctionner de cette façon, mais ce n'est pas important.) À tout le moins, les conditions de suppression des données devraient occuper une place prépondérante où aucun nouvel utilisateur qui lit quoi que ce soit à propos de Mosh pouvait raisonnablement ne pas le manquer. Si j'avais lu un tel avis avant que ma sortie ne soit perdue, même si je n'avais pas compris l'avertissement, j'aurais échangé ces jours d'aggravation avec un moment de "Oh _c'est ce que cela voulait dire !"

Je ne peux pas être d'accord avec Polyergic. Je pense que le site est bien fait et que l'interface avec les caractères soulignés indique bien qu'il y a une prédiction en cours. Je n'ai pas eu de problèmes de ne pas comprendre ce qui se passe. La seule chose qui m'a surpris, c'est que --predict=never ne faisait toujours pas fonctionner la sortie comme j'étais utilisé.

Donc, je demanderais peut-être simplement un commutateur (je peux alors bash-alias) qui transférerait tout. Il peut encore prédire.

Je vois donc trois options ici :

• prédiction + ne pas tout transférer (utile pour les liaisons à latence élevée et à faible bande passante)
• prédiction + tout transférer (utile pour les liaisons à latence élevée et à large bande passante)
• pas de prédiction + ne pas tout transférer (utile uniquement pour la persistance de la connexion)

Je tombe dans la 2. catégorie. Les liaisons transatlantiques vers l'Europe ont une latence de 100 ms, mais elles sont rapides. Je renommerais mosh en tash dans ce cas : coquillage transatlantique. :-)

@kmcallister

Émuler un terminal (écran) à l'intérieur d'un terminal émulé (mosh), afin
pour émuler la fonctionnalité native (scrollback) de l'émulateur de terminal englobant
(xterm, iterm) n'entraîne pas et ne peut pas aboutir à une expérience utilisateur acceptable.

C'est là le problème sous-jacent. Bien sûr, Mosh n'est pas non plus à blâmer pour
30 ans de stagnation dans le secteur des émulateurs de terminaux, et il ne peut pas non plus proprement
résoudre la situation à partir de l'endroit où il se trouve actuellement dans la pile.

D'où ma proposition d'un "mode muet", comme un pansement à court terme
pour les prochaines décennies.

@mitar , je ne vois aucun désaccord entre ce que j'ai dit et ce que tu as dit ; reformulant les choses laconiquement, ce que je vois est ceci:

J'ai dit : Mosh perd des données de manière inattendue ; Les descriptions de Mosh doivent définir des attentes correspondant à son comportement.

Vous avez dit : Le site Web de Mosh est sympa ; les indicateurs de prédiction sont sympas ; une option pour tout transférer serait bien.

Qu'est-ce que je rate? Avez-vous vu un avis clair quelque part indiquant que Mosh ne conservera pas toutes les sorties de vos commandes ?

@moe

L'émulation d'un terminal (écran) à l'intérieur d'un terminal émulé (mosh), afin d'émuler la fonctionnalité native (scrollback) de l'émulateur de terminal englobant (xterm, iterm) n'entraîne pas et ne peut pas aboutir à une expérience utilisateur acceptable.

Eh bien, pourriez-vous décrire en quoi l'expérience utilisateur est inacceptable ? Ce serait une information utile pour nous.

D'une manière générale, le monde de l'informatique regorge de niveaux d'imbrication et d'émulation apparemment ridicules qui offrent pourtant une expérience utilisateur parfaitement fine.

@kmcallister

Avant tout, frankenstack ne prend pas en charge le défilement natif. C'est un showstopper.
Le "mode copie" et les hacks de défilement virtuel ne remplacent pas. Il y a aussi une pléthore de plus subtils
problèmes, mais vous (en tant qu'auteur d'un émulateur de terminal) n'avez pas besoin que je vous en parle. ;)

Comme je l'ai dit, je ne blâme pas Mosh pour la situation terminale ridicule d'aujourd'hui - cela a été désastreux
bien avant que mosh n'existe. Compte tenu de la portée du projet, Mosh n'avait guère le choix d'autres
que de s'accroupir sur les épaules des gnomes, comme tout le monde, et pour cela, il ne s'en sort même pas trop mal.

Je dis juste qu'avec le supposé mode "stupide" mosh pourrait fonctionner pour ceux d'entre nous qui ont
aucun problème de latence et qui aimerait la persistance, mais ne tolère pas un scrollback cassé.

Un pansement sur le pansement, pour ainsi dire.

Jusqu'à ce que quelqu'un prenne enfin un cœur et remplace complètement l'émulation de terminal VT100 ...

J'aimerais aussi avoir un mode "stupide" qui me permette d'utiliser le défilement normal dans ma fenêtre de terminal pour consulter l'historique de ce que j'ai fait auparavant ou faire défiler la sortie d'une grande commande.

Je n'ai pas fait de trucs vt100 depuis mes jours BBS, alors n'hésitez pas à me frapper, mais ne pourriez-vous pas faire les deux choses ? Chaque fois que l'état de votre écran change de telle manière que vous devez faire défiler une ligne hors de l'écran, ne pourriez-vous pas simplement aller en bas et faire un cr/lf, faire défiler la ligne du haut hors de l'écran et dans le défilement arrière, puis continuez à synchroniser l'état de l'écran comme vous le faites maintenant ?

De toute évidence, nous pourrions perdre une partie de la sortie si nous nous déconnections et que des choses défilaient sur la page sur le serveur, mais je serais d'accord avec ça. Tant que cela fonctionnait pendant que je suis en ligne et que j'interagis avec le shell, je serais heureux. Je serais encore plus heureux si vous gardiez une trace du moment où les choses ont défilé en haut du côté du serveur que nous n'avons pas vu et que vous avez fait défiler une sorte de marqueur comme "mosh : 60 lignes ont défilé sur le serveur pendant que vous étiez hors ligne", mais c'est certainement dans le territoire du tour bonus. :-)

Pour être clair, j'exprime ici une préférence. Si c'est difficile et en conflit avec vos objectifs, alors c'est bien aussi. J'utiliserai mosh malgré tout, car les éléments de connexion sans état complètent vraiment ma façon de travailler. :-) Merci d'avoir créé ça !

@timspencer Je pense que ce que vous suggérez semble raisonnable mais peut ne pas être facile à mettre en œuvre. Ma compréhension est que mosh ne garde pas une trace du flux d'octets, il regarde simplement l'état actuel du terminal et calcule un diff avec l'état précédent, et envoie périodiquement des mises à jour au client. Si vous cat /dev/urandom , l'écran se mettra à jour très rapidement, mais mosh n'enverra pas _tout_ au client, il prendra juste des instantanés réguliers et enverra des diffs. Au moins c'est ma compréhension, je n'ai pas lu le code source.

Cela dit, ce serait vraiment génial d'avoir un mode de streaming où mosh diffuse tout et ne fait que la connexion persistante plus ses choses de prédiction.

Pouvons-nous séparer cela en deux problèmes? Le problème que j'ai signalé est que mosh devrait mettre le terminal en mode d'écran alternatif. Il s'agit d'une correction de bug claire que nous pouvons implémenter aujourd'hui. Il est requis pour l'émulation de la molette de la souris vers les touches fléchées de gnome-terminal dans les applications curses. (Ne confondez pas cela avec le protocole d'événement de souris xterm plus sophistiqué que personne n'utilise.)

Le deuxième problème qui découle de ce fil est que mosh ne prend pas en charge l'historique de défilement utile. Il est vrai qu'un des effets secondaires de la mise du terminal en mode écran alternatif serait que l'historique de défilement inutile de mosh deviendrait inaccessible. Je considère qu'il s'agit d'une fonctionnalité, pas d'un bug. Si nous voulons plus tard consacrer beaucoup de temps à la conception d'un système pour ajouter un défilement utile, ce serait génial. Mais c'est une demande de fonctionnalité totalement distincte, et ce n'est pas nécessaire pour ce que je comprends être le cas courant où l'utilisateur exécute simplement screen à l'intérieur mosh toute façon. Je propose de rouvrir le #122 pour cela.

Nous devrions corriger mosh maintenant pour mettre le terminal en mode écran alternatif, avec un commutateur de ligne de commande pour le désactiver (comme less -X ) pour les personnes qui pensent que le défilement cassé est plus important qu'une molette de souris qui fonctionne.

Anders, ok, je suis convaincu par cela pour 1.2.4 si cela signifie simplement ajouter smcup et rmcup à Terminal :: Emulator :: open() et Terminal :: Emulator :: close(). Accepteriez-vous de soumettre une pull request ? (Je suppose que nous voulons que les appels terminfo réels restent dans src/terminal/terminaldisplayinit.cc).

Je considère que l'émulation de la molette de la souris vers les touches fléchées de gnome-terminal est un bogue horrible. Il y a beaucoup de gens qui sont d'accord avec moi : https://bugzilla.gnome.org/show_bug.cgi?id=518405

Malheureusement, les développeurs GNOME ne sont pas d'accord avec l'interprétation du bogue, et andersk ne semble pas l'être non plus. Je vais essayer de vous convaincre (en vain, je suppose) qu'il s'agit bien d'un horrible bug. La raison pour laquelle le mappage des événements de la molette aux touches fléchées est mauvaise est que le défilement de la molette de la souris est censé être une opération _non destructive_. Mon modèle mental de la molette de la souris est que le défilement de la molette est censé uniquement modifier votre vue du tampon de défilement du terminal. Il ne doit jamais modifier l'état du terminal lui-même. Malheureusement, dans de nombreuses situations, telles que les clients IRC et de nombreux autres scénarios mentionnés dans le thread bugzilla GNOME, le comportement GNOME d'émulation des touches fléchées entraîne en fait la perte permanente de l'état du tampon d'entrée d'une application chaque fois que la molette de la souris est heurtée. Par exemple, disons que je suis en train de taper une ligne lorsque j'appuie sur la molette de la souris. La molette de la souris déclenche de manière exaspérante une pression sur la flèche du clavier, ce qui efface la ligne que je tapais. La résolution des applications individuelles est problématique étant donné le grand nombre d'applications qui présentent le problème.

Le fait que mosh ne parvienne pas à utiliser le mode d'écran alternatif a été une énorme bénédiction pour moi, car cela signifie que les événements accidentels de la molette de la souris ne détruisent pas l'état du client IRC depuis l'intérieur de mosh. Étant donné que toute mon utilisation du client IRC se produit dans mosh, cette fonctionnalité (involontaire?) De mosh neutralise complètement le bogue GNOME sous-jacent pour moi. Je serais très triste de voir ce comportement disparaître.

Si vous choisissez de mettre en œuvre cette idée complètement folle, veuillez (comme le suggère andersk) fournir un commutateur pour la désactiver. Ce n'est pas que je préfère le défilement brisé. C'est que je déteste la perte de données par-dessus toute autre considération, et les touches fléchées indésirables entraînent une perte de données.

(En ce qui concerne le deuxième problème de ce bogue, dans lequel mosh provoque la perte de données du contenu de défilement, je soutiens bien sûr fortement tout effort visant à modifier mosh pour préserver les données de défilement. Il n'y a rien au monde qui soit plus important que d'éviter la perte de données.)

davidjao : gnome-terminal fournit déjà une case à cocher (Édition → Préférences du profil → Défilement → Utiliser les touches pour faire défiler sur un autre écran) pour désactiver complètement l'émulation des touches fléchées. Mais personne ne conteste qu'il pourrait aussi bien y avoir un commutateur de ligne de commande pour ceux qui ont besoin de contourner ce problème sur une base par application pour une raison quelconque.

Cette case à cocher n'existe que sur Ubuntu et les dérivés d'Ubuntu. Il n'est pas inclus dans le terminal gnome en amont, et d'autres distributions telles que Fedora, Debian, Arch, etc. ne le fournissent pas. Bien sûr, vous pouvez le réparer vous-même, mais c'est pénible.

Je comprends que nous convenons tous qu'un commutateur de ligne de commande est souhaitable, mais je crains qu'il ne soit omis ou considéré comme sans importance. C'est pourquoi je voulais dire pourquoi c'est important.

Merci à tous, l'option --no-init fonctionne parfaitement pour désactiver le mode d'écran alternatif pour ceux d'entre nous qui n'en veulent pas.

Dans l'esprit de maintenir la documentation à jour, pourrait-on mentionner dans la page de manuel (dans la section VARIABLES D'ENVIRONNEMENT) que la variable MOSH_NO_TERM_INIT inhibe smcup/rmcup ?

Pour moi, l'option "--no-init" ne résout pas le problème de défilement avec la molette de la souris.

"--no-init" est complètement cassé ici avec le terminal XFCE : une partie de la sortie est oubliée dans l'historique et la barre de défilement est mise à jour de manière incohérente. Pourquoi mosh ne peut-il pas simplement se comporter comme ssh ? Être opiniâtre, c'est bien, mais il serait également agréable de bénéficier des améliorations de la mise en réseau sans que des décisions d'émulation de terminal différentes soient imposées à l'utilisateur.

le

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

la solution de contournement fonctionne. Quelle serait la commande équivalente pour utiliser tmux au lieu de screen et s'assurer qu'aucun processus tmux n'est laissé de côté lorsque je me déconnecte ?

Merci.

En fait, j'ai parlé trop tôt. La solution de contournement de l'écran a des problèmes. Si je l'utilise dans deux fenêtres de terminal distinctes, l'une après l'autre, la deuxième fenêtre détourne l'écran de la première fenêtre. Ce serait formidable d'avoir un défilement pour éliminer le besoin de cela. Merci.

@dtenenba , ce n'est pas un forum de support pour tmux et screen. Lisez les pages de manuel ( tmux(1) , screen(1) ), en particulier les parties sur l'option -d de tmux attach-session , et les -d , -r , -x options à screen .

Je voudrais attirer l'attention sur cet article . Il décrit une configuration simple et agréable combinant mosh et tmuc résultant en un historique de défilement (avec la souris) sur les terminaux prenant en charge la souris xterm. Sur OS X, c'est iTerm ou même Terminal.app avec le plugin easySIMBL et MouseTerm .

Il semble que ce n'est toujours pas vraiment mis en œuvre? L'exécution mosh -n --no-init désactive toujours le défilement pour moi ? (Mac OS X avec Terminal.)

--no-init n'existe que pour restaurer le comportement pré-1.2.4 de ne pas désactiver la barre de défilement du terminal, pour apaiser ceux qui pensaient que la fonctionnalité était perdue. Mosh n'a jamais été en mesure de garantir que le tampon de défilement du terminal sera réellement rempli de quoi que ce soit, et encore moins de quoi que ce soit d'utile, en raison de la façon dont il optimise les deltas de trame dans son protocole de synchronisation d'état. Voir #122.

Ce serait vraiment bien si mosh supportait le défilement arrière. J'utilise mysql sur le serveur et la sortie de Describe est plus longue que l'écran, il m'est donc impossible de voir le haut. Eh bien, revenons à ssh, je suppose.

Dans la cli mysql, vous pouvez simplement faire pager less et la sortie sera redirigée vers less au lieu d'être imprimée directement.

@tsuna Merci ! Cette commande est géniale

un espoir que ce soit corrigé un jour ?

Le drapeau --no-init fonctionne parfois parfois non. Nous espérons voir un support de défilement natif avec Mosh.

Dernier iTerm2 sur macOS Sierra 10.12.5

Oui, c'est un gros problème pour moi. Je l'utiliserai une fois que ce problème évident sera corrigé.

Je ne sais vraiment pas de quoi il s'agit, si vous voulez que le défilement utilise screen ou tmux, ce sont de merveilleux outils, et les utiliser de manière appropriée vous permettra de faire bien plus que d'essayer d'intégrer plus de fonctionnalités dans mosh. La philosophie unix pour les outils, bien faire une chose, est PARFAITEMENT illustrée dans ce cas. https://en.wikipedia.org/wiki/Unix_philosophy

Je viens de tester cela sur ma machine locale en me connectant à une autre machine. Je me connecte à l'aide de mosh, me reconnecte à tmux en utilisant -- tmux attach comme argument de la chaîne de connexion, et je suis reconnecté à ma session avec la possibilité de faire défiler l'historique, de faire défiler ma "barre de fenêtre" tmux pour aller à différents volets, en bref tout ce que les gens ont demandé ci-dessus SANS aucune modification de mosh.

Si vous faites défiler les commandes précédentes, vous n'utilisez probablement que mosh ou vous êtes à l'écran. Il le fait que vous vous connectiez via SSH ou mosh, car il utilise lui-même "l'écran alternatif". J'aime l'écran, mais tmux est bien meilleur pour plusieurs commandes et sessions, et gère le défilement et l'historique d'une manière beaucoup plus saine à mon avis.

@dragon788 content d'entendre ça. Mais pouvez-vous faire défiler vers le haut à l'aide de la souris
parce que vous avez mentionné que vous pouviez faire défiler en utilisant la "barre de fenêtre" que je
pense pas un problème ici.

Le samedi 21 octobre 2017 à 6 h 26, dragon788 [email protected] a écrit :

Je ne sais vraiment pas de quoi il s'agit, si vous voulez utiliser le défilement
screen ou tmux, ce sont de merveilleux outils, et les utiliser correctement
vous permet de faire bien plus que d'essayer d'intégrer plus de fonctionnalités dans mosh. L'Unix
la philosophie des outils, bien faire une chose, est PARFAITEMENT illustrée dans ce
Cas. https://en.wikipedia.org/wiki/Unix_philosophy

Je viens de tester cela sur ma machine locale en me connectant à une autre machine. je
connectez-vous à l'aide de mosh, reconnectez-vous à tmux en utilisant -- tmux attach comme
argument de la chaîne de connexion, et je suis reconnecté à ma session avec
la possibilité de faire défiler l'historique, de faire défiler ma "barre de fenêtre" tmux jusqu'à
aller dans différents volets, bref tout ce que les gens demandent
ci-dessus SANS aucune modification de mosh.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/mobile-shell/mosh/issues/2#issuecomment-338336608 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABhWeSFAPBiXYl3BA5W4lb43V_fw2f_Lks5suR4HgaJpZM4ABSOa
.

>

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

L'agitation n'a rien à voir avec le manque de fonctionnalité de défilement. Le problème est qu'en mode écran alternatif, les événements de la molette de la souris détruisent le tampon de commande actuel car un événement de la molette de la souris est interprété comme une touche fléchée. Ceci est dévastateur car cela signifie qu'un défilement accidentel entraîne une perte de données.

Votre suggestion semble être "n'utilisez pas l'écran GNU", mais ce conseil est intenable pour de nombreuses raisons évidentes.

@edbergavera Je fais défiler en arrière en utilisant l'historique tmux via le mode copie (qui préserve la sortie de la commande sur la télécommande, qui IMO car c'est là que les commandes s'exécutent et où il est vraiment important de savoir où l'historique doit être). Je pense que vous pouvez utiliser la molette de défilement de la souris si vous avez un plugin pour tmux qui interprète les codes d'échappement de la molette de défilement comme un signal pour entrer en mode copie et faire défiler, ou vous pouvez simplement préfixer + [ ou tout ce que vous liez pour entrer en mode copie, puis faites défiler avec votre souris en supposant que votre terminal ne capture pas les événements et les transmet intacts au serveur. Préfixe + Esc est un autre équivalent.

Qu'en est-il d'un indicateur indiquant la quantité d'historique à charger au démarrage (comme tail -n) ?

Je suis triste que cela soit toujours ouvert, j'ai vérifié tous les deux ans pour voir si le support de défilement natif a été résolu, mais jusque-là, je ne peux malheureusement pas l'utiliser.

Pour clarifier, je me soucie uniquement de me reconnecter de manière fiable après une panne de réseau sans prorams sur l'hôte distant se terminant.

Je ne peux pas croire que cela ne soit jamais réparé :( C'est un cauchemar. ssh meurt. mosh n'est pas utilisable.

Mosh installé pour l'utiliser au travail avec une connexion 4G instable. On dirait que cela fonctionne très bien sur de mauvaises connexions, mais les fonctionnalités de défilement manquantes en font un non-aller pour moi. Je l'ai désinstallé instantanément car je préfère me reconnecter à SSH plusieurs fois par jour plutôt que de manquer cette fonctionnalité essentielle.

@mr-propre C'est vraiment un fait fondamental de la convivialité. Je l'utilise pour me connecter aux clusters Spark car ssh échoue, puis j'utilise screen avec CTRL-A, Escape puis page up/down pour faire défiler mais c'est énervant et le tampon est trop petit.

Je ne sais pas si cela a déjà été mentionné ici, mais si vous êtes concerné par ce problème, vous voudrez peut-être jeter un œil à Eternal Terminal comme alternative.

Les gens - vous réalisez que vous pouvez ajuster la quantité de défilement que l'écran et le tmux enregistrent ?

C'est un problème résolu pour la plupart des gens (qui utilisent screen/tmux, ou même moins, côté serveur). Mosh n'obtiendra probablement pas son propre protocole de défilement à distance de si tôt.

Je suis au courant. C'est juste nul que le client ne gère pas ça comme les autres
celui dont j'ai jamais entendu parler.

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

Le mar. 13 août 2019 à 12 h 54 Keith Winstein [email protected]
a écrit:

Gens - vous réalisez que vous pouvez ajuster la quantité de défilement de cet écran
et tmux enregistrer?

C'est un problème résolu pour la plupart des gens (qui utilisent screen/tmux, ou
encore moins, côté serveur). Mosh n'obtient probablement pas le sien
protocole de défilement à distance de sitôt.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/mobile-shell/mosh/issues/2?email_source=notifications&email_token=AAAKJJKV4Y2R4PB2E6UWYL3QEMGPNA5CNFSM4AAFEONKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4GZK3I#issuecomment-5209,83-52
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAAKJJMBSF2QEQUAEBR5X5TQEMGPNANCNFSM4AAFEONA
.

Ce problème est vraiment ennuyeux - jusqu'à ce que vous appreniez à utiliser tmux. Ensuite, ce n'est plus un problème.

Je suis désolé mais je ne suis pas d'accord. De mon point de vue, devoir utiliser tmux est un peu compliqué. Si je voulais utiliser tmux, je serais assez bon avec ssh + tmux.

En fait, je serais curieux de savoir quel est l'avantage de "mosh + tmux" par rapport à "ssh + tmux" ?? Qu'est-ce que les gens pensent?

La plupart des mêmes avantages mosh s'appliquent toujours lors de l'utilisation de tmux :

• Connectivité transparente lorsque votre client change de réseau ou que votre ordinateur client sort d'un état suspendu/hiberné
• écho local
• meilleure gestion du contrôle-C

J'ai essayé tmux et screen mais ils ne résolvent pas le plus gros problème que j'ai avec mosh : je ne peux pas coller de code Python dans le terminal. Je vais créer un problème séparé : https://github.com/mobile-shell/mosh/issues/1066

Moi-même, je ne m'oppose pas à l'utilisation de tmux, mais le défilement à l'aide de tmux est lent car il nécessite d'attendre que le serveur distant envoie le contenu de l'écran mis à jour. L'un des principaux arguments de vente de Mosh est qu'il offre une meilleure interactivité que ssh sur des réseaux lents ou peu fiables. Cependant, en ce qui concerne le défilement, s'appuyer sur tmux offre une moins bonne interactivité que le défilement local.

Serait-il difficile d'ajouter une restauration à mosh ? Qu'est-ce qui est impliqué ?

mais le défilement à l'aide de tmux est lent car il nécessite d'attendre que le serveur distant envoie le contenu de l'écran mis à jour

Si mosh apprend un jour à faire défiler vers l'arrière, j'imagine qu'il devrait faire la même chose, donc je ne comprends pas très bien cette plainte.

Pourquoi devrait-il faire la même chose? En principe, Mosh devrait pouvoir conserver une copie locale du tampon de défilement. Je suppose qu'il pourrait y avoir des problèmes si quelque chose spamme le terminal assez rapidement pour que le client ne reçoive pas tout le texte (puisque Mosh limite intentionnellement les mises à jour de l'écran à une fréquence d'images fixe). Mais c'est résoluble; Mosh aurait besoin d'une sorte d'algorithme pour synchroniser le contenu de défilement avec le serveur, idéalement avec une priorité inférieure aux mises à jour d'écran.

Nous sommes en 2020 et le numéro 2 est toujours ouvert... oh boy...

Je ne sais vraiment pas de quoi il s'agit, si vous voulez que le défilement utilise screen ou tmux, ce sont de merveilleux outils, et les utiliser de manière appropriée vous permettra de faire bien plus que d'essayer d'intégrer plus de fonctionnalités dans mosh. La philosophie unix pour les outils, bien faire une chose, est PARFAITEMENT illustrée dans ce cas. https://en.wikipedia.org/wiki/Unix_philosophy

@ dragon788 si quoi que ce soit, cela montre les inconvénients de _not_ suivant la philosophie Unix. Mosh brise la philosophie Unix en faisant bien plus qu'une chose, il se retrouve donc dans la position où il s'agit d'un émulateur de terminal à part entière, mais très limité sans prise en charge du défilement.

C'est bien pour un vrai émulateur de terminal (enfer, j'utilise st et j'essaie d'autres émulateurs de terminaux sans défilement), mais quand Mosh le fait, il casse le défilement existant, ce qui va au-delà de la simple prise en charge du défilement. J'utilise déjà tmux pour héberger la session Mosh, alors pourquoi devrais-je également démarrer une autre session tmux côté serveur ?

Maintenant, le _server_ (et c'est _every_ server auquel vous voulez vous connecter) doit avoir tmux ou similaire installé juste pour contourner le _breaking_ de défilement de Mosh (pas simplement son manque de support pour cela), alors comment est-ce suivant la philosophie Unix, exactement ?

ssh établit la norme ici. Mosh viole cette norme, nécessitant l'ajout d'un logiciel entièrement nouveau que la plupart des utilisateurs ne veulent pas sur le serveur, de sorte que les gens n'utilisent pas Mosh autant qu'ils le feraient s'il prenait en charge le défilement comme les utilisateurs l'attendent parce que les alternatives le prennent en charge. . Il y a une forte attitude de "pas mon problème" bien qu'il s'agisse d'un problème très réel pour la majorité des utilisateurs de Mosh qui limite l'impact du travail des contributeurs de Mosh sur le projet. De toute évidence, l'open source consiste à mettre votre argent là où vous en avez la bouche et à ajouter ce dont vous avez besoin. Je ne suis pas en mesure d'ajouter cette fonctionnalité, donc moi et beaucoup d'autres comme moi n'utilisons Mosh que si nous y sommes absolument obligés. J'espère que quelqu'un interviendra et ajoutera cette fonctionnalité car il s'agit d'une lacune majeure dans Mosh en tant que projet open source et sa disponibilité augmentera considérablement l'adoption de Mosh et rendra de nombreux utilisateurs très heureux.

La façon dont vous avez fermé le ticket signifie que personne ne va intervenir et apporter cette contribution, ce qui est malheureux. Le moins que vous puissiez faire pour votre communauté est d'arrêter de vous renvoyer la balle et d'abuser de la philosophie Unix et d'admettre simplement que vous n'avez pas envie de l'ajouter et de laisser quelqu'un d'autre intervenir et le faire. "Pas mon problème" peut vous faire vous sentir mieux d'avoir moins de tickets ouverts, mais cette attitude sape le projet et ses utilisateurs. Ce ticket a 76 commentaires. Combien de vos autres billets ont 76 commentaires ? Je vous suggère de réfléchir à la raison pour laquelle vous contribuez à l'open source et si vous appréciez votre communauté avec cette attitude.

Veuillez ouvrir ce ticket et au moins laisser quelqu'un d'autre intervenir et ajouter cette capacité essentielle.

Je ne sais vraiment pas de quoi il s'agit, si vous voulez que le défilement utilise screen ou tmux, ce sont de merveilleux outils, et les utiliser de manière appropriée vous permettra de faire bien plus que d'essayer d'intégrer plus de fonctionnalités dans mosh. La philosophie unix pour les outils, bien faire une chose, est PARFAITEMENT illustrée dans ce cas. https://en.wikipedia.org/wiki/Unix_philosophy

@ dragon788 si quoi que ce soit, cela montre les inconvénients de _not_ suivant la philosophie Unix. Mosh brise la philosophie Unix en faisant bien plus qu'une chose, il se retrouve donc dans la position où il s'agit d'un émulateur de terminal à part entière, mais très limité sans prise en charge du défilement.

C'est bien pour un vrai émulateur de terminal (enfer, j'utilise st et j'essaie d'autres émulateurs de terminaux sans défilement), mais quand Mosh le fait, il casse le défilement existant, ce qui va au-delà de la simple prise en charge du défilement. J'utilise déjà tmux pour héberger la session Mosh, alors pourquoi devrais-je également démarrer une autre session tmux côté serveur ?

Maintenant, le _server_ (et c'est _every_ server auquel vous voulez vous connecter) doit avoir tmux ou similaire installé juste pour contourner le _breaking_ de défilement de Mosh (pas simplement son manque de support pour cela), alors comment est-ce suivant la philosophie Unix, exactement ?

Ce. Tellement ça.

Ramenons cette conversation depuis l'orbite terrestre basse, les gars. La raison pour laquelle Mosh ne prend pas en charge le défilement n'a rien à voir avec la philosophie. Cela n'a également rien à voir avec le fait que ce ticket soit ouvert ou fermé - il y a déjà un ticket ouvert pour le défilement, et ce n'est pas ce ticket, qui concernait le mode d'écran alternatif. Cela a tout à voir avec le temps limité du développeur. Si vous avez lu l'article de Mosh, vous comprendrez comment la façon dont Mosh donne la priorité à l'interactivité rend difficile la livraison d'un défilement utilisable, de sorte qu'il a été omis de l'implémentation initiale et personne n'a eu le temps de l'ajouter depuis. Si nous avions un temps infini pour travailler sur Mosh, une fonction de défilement serait probablement une priorité. Personne ne vous empêche de développer cette fonctionnalité si vous êtes intéressé, et comme toujours, une pull request bien conçue et bien implémentée est susceptible d'être acceptée. Mais se plaindre d'un problème clos ne va pas accélérer les choses.

@andersk Je pense que c'est cette priorité de l'interactivité qui est considérée comme une déviation de la philosophie unix. Mosh fait à la fois des connexions qui ne meurent pas (une fonctionnalité que j'aimerais beaucoup) et de l'interactivité (une fonctionnalité dont le prix, un défilement qui n'est pas un pur flux ascii complet, je ne suis pas prêt à payer). Ce que les gens semblent demander, c'est la fiabilité sans l'interactivité car ils pensent que le mode écran alternatif est un prix trop élevé à payer.

D'un point de vue pragmatique, je ne suis pas vraiment intéressé à savoir si Mosh suit ou non la philosophie UNIX ; tout ce que je sais en tant qu'utilisateur, c'est que c'est un excellent logiciel à _utiliser_, à l'exception de ce défaut flagrant.

Je ne suis pas ici pour supplier l'auteur d'ajouter la fonctionnalité gratuitement, je comprends que c'est ce qu'elle est et qu'on ne me doit pas de code, de temps, d'efforts ou quoi que ce soit.

Mon commentaire critiquait _seulement_ l'affirmation selon laquelle (en paraphrasant) « Mosh ne devrait pas faire cela parce que cela va à l'encontre de la philosophie Unix » ; mon contraire est que la raison pour laquelle Mosh doit faire cela en premier lieu est exactement _parce_ que c'est déjà allé à l'encontre de la philosophie Unix. Je ne porte pas de jugement sur le fait que ce soit bon ou mauvais, je ne sais pas quels étaient tous les compromis et ce qui _ne pas_ suivre la philosophie Unix a acheté Mosh.

Ma solution en attendant est de ne pas utiliser Mosh. J'espère que je serai en mesure de mettre en place une prime dans un proche avenir maintenant que je suis à nouveau au courant de Mosh et de ce qui se dresse sur son chemin pour moi. Au-delà de cela, je continuerai à utiliser SSH et je ferai savoir respectueusement à l'auteur que c'est la seule chose qui m'empêche d'utiliser Mosh (les gens se soucient généralement du fait que certaines personnes ne bénéficient pas de leur travail tant que ces personnes ne sont pas grossières) .

@rjurney Je suis presque sûr que la personne qui cite la philosophie Unix n'est pas l'auteur. Il n'y a aucune raison d'être aussi sévèrement critique.

L'auteur a également un problème ouvert sur scrollback . C'est verrouillé parce que la discussion est pratiquement terminée. Nous le voulons tous, mais aucun d'entre nous ne l'aura tant que certains d'entre nous ne l'auront pas mis en œuvre. Mais la question est ouverte. Cela dépend de nous tous maintenant, pas seulement du créateur.

Je vais déverrouiller le problème ouvert sur le défilement, car il a eu une chance de se calmer. Cependant, veuillez éviter de commenter ce problème (ou ce problème) s'il n'y a rien de nouveau à ajouter. Il y a des boutons de "réaction" dans github qui peuvent être utilisés pour exprimer votre intérêt (qui ne spamment pas tout le fil), et les commentaires comme "+1" ne sont pas utiles. Nous savons que c'est un problème très important pour certaines personnes et que l'exécution de screen/tmux sur le serveur n'est pas toujours une solution pratique ou acceptable.

Les commentaires sur la philosophie Unix sont intéressants, mais sont définitivement __hors sujet__ pour ce traqueur de problèmes github. (Cependant, vous pouvez rejoindre notre canal IRC #mosh sur freenode pour discuter de telles choses).

Je ne sais pas si cela a déjà été mentionné ici, mais si vous êtes concerné par ce problème, vous pouvez jeter un œil à Eternal Terminal comme alternative.

Eternal Terminal n'a pas de paquet binaire pour centos 7, j'ai récemment passé des heures à le compiler manuellement et j'ai finalement abandonné.