Mosh: Desplazamiento hacia atrás y pantalla alternativa (era: Usar pantalla alternativa en smcup/rmcup)

O tal vez el cliente siempre debería poner la terminal real en modo de pantalla alternativa, por la misma razón que lo hacen las aplicaciones curses: el historial de desplazamiento hacia atrás que genera en la pantalla principal no es particularmente útil de todos modos.

En uso normal (como escribir línea por línea en el shell), el desplazamiento hacia atrás del terminal real será algo útil. No estoy seguro de querer renunciar a eso por completo, aunque tal vez al usuario le moleste que las impresiones más grandes solo estén parcialmente en el desplazamiento hacia atrás.

Hola, me gustaría saber si tienen algún plan sobre este tema. Creo que mosh debería funcionar como ssh, que entrará en modo smcup cuando la aplicación remota lo solicite. Me resulta bastante molesto cuando uso vim para abrir un archivo grande y deja muchos retrocesos.

Aquí está la solución propuesta actual:

(a) mosh-client pone el terminal en la pantalla alternativa todo el tiempo

(b) mosh-server interpreta SMCUP/RMCUP de la forma en que lo hace xterm, por lo que el "vim" de las personas continúa funcionando igual que en xterm (o en la pantalla con altscreen habilitado)

(c) tomamos control-PgUp y control-PgDown para nuestros propios fines tortuosos (proporcionando un desplazamiento hacia atrás adecuado).

Suena razonable para mí. Propuse las siguientes modificaciones a (c):

• también tomamos Ctrl-Up y Ctrl-Down (ya que esto es lo que envía Ctrl-wheel en gnome-terminal)
• pero no tomamos ninguna tecla para retroceder mientras la aplicación interna está dentro de una pantalla alternativa.

¿Entiendo correctamente que el plan aquí es proporcionar un desplazamiento hacia atrás similar al que proporciona una terminal normal? Es decir, si ejecuto un comando con muchos resultados, ¿puedo desplazarme de manera confiable hacia atrás con las barras de desplazamiento de mi terminal para ver todo lo que generó ese comando? Ese es un tema de usabilidad muy importante para mí. ¡Gracias!

Sí, Scott, ese es el plan, aunque no podrás usar las barras de desplazamiento de tu terminal local. Por ahora, puede usar screen o tmux en el lado del servidor para obtener esta función.

Esta es una idea genial. ¿Es posible soportar la rueda del ratón también?

Sí, si lo hacemos con la enmienda de Anders, admitirá la rueda del mouse.

Acordado. Este es el único problema importante con Mosh en este momento. Es el único problema que ha contaminado mi experiencia.

+1

+1

Estoy de acuerdo. Prefiero leer una página entera de basura PGP :)

Estoy de acuerdo. Prefiero leer una página entera de basura PGP :)

+1

(Yo... simplemente... no pude resistir...)

+1 a eso

+1 por arreglar el desplazamiento hacia atrás en mosh (stopper para mí)

-2 mkaysi

+1, a veces cat un archivo en el servidor para copiarlo localmente y no admitir el desplazamiento hacia atrás lo impide.

+1 por corregir el desplazamiento hacia atrás (el único problema real con mosh hasta ahora).

+1 para corregir el desplazamiento hacia atrás, -1 para mkaysi, me pregunto por qué mosh no puede comportarse como ssh en esto. Tengo directorios enormes que "ls" todo el día, así que tengo que usar ssh.

Al igual que SSH shell seguro, pero permite la movilidad y más receptivo y robusto.

@ubershmekel : puede usar screen o tmux en el lado remoto para desplazarse hacia atrás. O simplemente ls | less .

Me pregunto por qué mosh no puede simplemente comportarse como ssh en esto.

Me alegra que hayas preguntado. :)

SSH simplemente transmite un flujo de bytes del servidor al cliente; no le importa lo que representan los bytes. Entonces, el terminal local (XTerm o lo que sea) obtiene todo el historial en orden y puede desplazarse.

Por el contrario, Mosh rastrea el estado _actual_ de la terminal en el lado del _servidor_ y luego sincroniza esta representación entre el cliente y el servidor. Esta es la decisión de diseño clave que permite las características únicas de Mosh: roaming, eco local y una mejor utilización de las malas conexiones. Por otro lado, complica algunas cosas que son simples en el mundo de SSH de transportar bytes en orden.

Para admitir el desplazamiento hacia atrás, necesitaremos agregar un historial a este objeto de estado de terminal y aumentar el protocolo para que el cliente pueda solicitar fragmentos de historial a pedido, a medida que el usuario se desplaza. (Si no lo hacemos bajo demanda, perdemos una ventaja clave de Mosh sobre SSH, que es que los comandos que lanzan la salida se actualizarán a una "velocidad de fotogramas" fija en lugar de retrasar la conexión).

Esto es ciertamente factible y obviamente es algo que mucha gente quiere. Pero en realidad no es "simplemente haz lo mismo que SSH" y no es un cambio trivial. Mientras tanto, creo que ejecutar screen o tmux en el lado del servidor es una buena solución (y tiene muchas otras ventajas).

Debo decir que ejecutar screen en el servidor era exactamente lo que esperaba evitar con mosh. Esto es lo que estaba haciendo con SSH cuando temía que la conexión se interrumpiera debido al cambio de IP o algo así. Con mosh, esperaba poder ejecutarlo y todo lo demás se solucionaría automáticamente.

Incluso podrías integrar mosh con screen. :-)

@kmcallister

Me pregunto si mosh podría desarrollar un modo alternativo en el que omita toda la magia pty y actúe como ssh normal.

Por supuesto, esto eliminaría el beneficio de la optimización de la latencia, pero creo que muchas personas (al menos yo) solo están interesadas en la persistencia de la conexión de todos modos. En este modo, se restauraría una pantalla simplemente reproduciendo los últimos n bytes incondicionalmente. Hacer un seguimiento de los desplazamientos del búfer local/remoto para activar la cantidad correcta de reproducción en los momentos correctos debería ser bastante fácil entonces...

Con mosh, esperaba poder ejecutarlo y todo lo demás se solucionaría automáticamente.

Tu puedes correr

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

Esto también ayuda con otro problema. Si un mosh-client muere inesperadamente (por ejemplo, porque la máquina cliente se quedó sin energía), el mosh-server correspondiente permanecerá inútilmente. Pero ejecutar screen -dR hará que el otro proceso screen se cierre, matando a ese antiguo mosh-server . Por supuesto, puede hacer esto más sofisticado con sesiones con nombre screen y demás.

@moe: lo que describe es factible, pero soy reacio a agregar modos alternativos a Mosh que cambien fundamentalmente el principio operativo. ¿Quizás algo como autossh satisfaga sus necesidades?

Intenté usar Mosh para la persistencia de la conexión, y nada de lo que leí antes de usarlo me dio una clara indicación de que era algo más que un shell ordinario con un transporte mejorado. Cuando Mosh descartó algún resultado importante, no tenía idea de lo que estaba pasando, y perdí algunos días (tiempo del calendario, varias horas de resolución de problemas reales) mirando todo lo demás porque no se me ocurrió que una herramienta para conexiones persistentes y una mejor latencia también tiraría mis datos. Después de eso, no puedo confiar en usted, no porque la forma en que funciona Mosh no sea razonable, sino porque la forma en que se describe no logra transmitir que no puede contar con recibir la salida completa de cualquier comando. (Sospecho que tampoco logra transmitir los objetivos que impulsaron la decisión de hacer que funcionara de esa manera, pero eso no es importante). Como mínimo, las condiciones para descartar datos deben tener una posición destacada donde ningún usuario nuevo que lea nada sobre Mosh podría razonablemente dejar de perdérselo. Si hubiera leído ese aviso antes de que se perdiera mi producción, incluso si no hubiera entendido la advertencia, habría intercambiado esos días de irritación con un momento de "¡Oh, eso es lo que eso significaba!"

No puedo estar de acuerdo con Polyergic. Creo que el sitio está muy bien hecho y también la interfaz con los caracteres subrayados dice muy bien que se está haciendo una predicción. No tuve problemas de no entender lo que está pasando. Lo único que me sorprendió fue que --predict=never todavía no hacía que la salida funcionara como estaba acostumbrado.

Entonces, tal vez solo recomendaría un cambio (puedo bash-alias) que transferiría todo. Todavía puede predecir.

Así que veo tres opciones aquí:

• predicción + no transferir todo (útil para enlaces de alta latencia y bajo ancho de banda)
• predicción + transferir todo (útil para enlaces de alta latencia y alto ancho de banda)
• sin predicción + no transferir todo (útil solo para la persistencia de la conexión)

Caigo en 2. categoría. Los enlaces transatlánticos a Europa tienen una latencia de 100 ms, pero son rápidos. Cambiaría el nombre de mosh a tash en este caso: caparazón transatlántico. :-)

@kmcallister

Emular una terminal (pantalla) dentro de una terminal emulada (mosh), para
para emular la funcionalidad nativa (scrollback) del emulador de terminal adjunto
(xterm, iterm) no da ni puede dar como resultado una experiencia de usuario aceptable.

Ese es el problema de fondo aquí. Por supuesto, Mosh tampoco tiene la culpa de
30 años de estancamiento en el negocio de los emuladores de terminales, tampoco puede limpiamente
resolver la situación desde donde se encuentra actualmente en la pila.

De ahí mi propuesta de un 'modo tonto', como una tirita a corto plazo
para las próximas décadas.

@mitar , no veo ninguna discrepancia entre lo que dije y lo que dijiste; Replanteando las cosas concisamente, lo que veo es esto:

Dije: Mosh pierde datos de forma inesperada; Las descripciones de Mosh deben establecer expectativas que coincidan con su comportamiento.

Dijiste: El sitio web de Mosh es bueno; los indicadores de predicción son agradables; una opción para transferir todo sería bueno.

¿Qué me estoy perdiendo? ¿Viste un aviso claro en alguna parte de que Mosh no guardará todos los resultados de tus comandos?

@moe

Emular una terminal (pantalla) dentro de una terminal emulada (mosh), para emular la funcionalidad nativa (desplazamiento hacia atrás) del emulador de terminal adjunto (xterm, iterm) no resulta ni puede resultar en una experiencia de usuario aceptable.

Bueno, ¿podría describir qué es inaceptable sobre la experiencia del usuario? Esta sería una información útil para nosotros.

En general, el mundo de las computadoras está lleno de niveles aparentemente ridículos de anidamiento y emulación que, sin embargo, brindan una experiencia de usuario perfectamente buena.

@kmcallister

Ante todo, frankenstack no admite el desplazamiento nativo. Eso es espectacular.
El 'modo de copia' y los trucos de desplazamiento virtual no son sustitutos. También hay una plétora de más sutiles
problemas, pero usted (como autor de un emulador de terminal) no necesita que le cuente sobre ellos. ;)

Como dije, no culpo a mosh por la ridícula situación terminal de hoy, ha sido terrible.
desde mucho antes de que mosh existiera. Dado el alcance del proyecto, Mosh no tenía otra opción
que agacharse sobre los hombros de los gnomos, como todo el mundo, y para eso ni siquiera le está yendo tan mal.

Solo digo que con el supuesto modo 'tonto' mosh podría funcionar para aquellos de nosotros que tenemos
no hay problemas con la latencia y a quién le gustaría la persistencia, pero no puede tolerar un desplazamiento hacia atrás roto.

Una tirita encima de la tirita, por así decirlo.

Solo hasta que alguien finalmente tome un corazón y reemplace la emulación de terminal VT100 por completo...

También me encantaría tener un modo "tonto" que me permita usar el desplazamiento hacia atrás normal en la ventana de mi terminal para ver el historial de lo que hice antes o desplazarme por la salida de un comando grande.

No he hecho cosas de vt100 desde mis días en BBS, así que siéntete libre de golpearme, pero ¿no podrías hacer ambas cosas? Cada vez que el estado de su pantalla cambia de tal manera que tiene que desplazar una línea hacia arriba fuera de la pantalla, ¿no podría simplemente ir al final y hacer un cr/lf, desplazando la línea superior fuera de la pantalla y retrocediendo? luego continuar sincronizando el estado de la pantalla como lo haces ahora?

Claramente, podríamos perder algo de salida si nos desconectamos y las cosas se desplazan fuera de la página en el servidor, pero estaría de acuerdo con eso. Siempre y cuando funcione mientras estoy en línea e interactuando con el shell, sería feliz. Sería aún más feliz si hicieras un seguimiento de las cosas que se desplazaron desde la parte superior del lado del servidor que no vimos y se desplazaron fuera de algún tipo de marcador como "mosh: 60 líneas se desplazaron en el servidor mientras estabas desconectado", pero eso ciertamente está en el territorio de la ronda de bonificación. :-)

Para ser claro, estoy expresando una preferencia aquí. Si es difícil y entra en conflicto con tus objetivos, también está bien. Usaré mosh de todos modos, porque la conexión sin estado realmente complementa mi forma de trabajar. :-) ¡Gracias por crear esto!

@timspencer Creo que lo que sugiere suena razonable pero puede que no sea fácil de implementar. Tengo entendido que mosh no realiza un seguimiento del flujo de bytes, solo mira el estado actual de la terminal y calcula una diferencia con el estado anterior, y envía actualizaciones al cliente periódicamente. Si cat /dev/urandom , la pantalla se actualizará muy rápidamente, pero mosh no enviará _todo_ al cliente, solo tomará instantáneas periódicas y enviará diferencias. Al menos eso es lo que entiendo, no he leído el código fuente.

Habiendo dicho eso, sería increíble tener un modo de transmisión en el que mosh solo transmite todo y solo hace que la conexión sea persistente más sus predicciones.

¿Podemos separar esto en dos cuestiones? El problema que informé es que mosh debería poner la terminal en modo de pantalla alternativa. Esta es una corrección de errores clara que podemos implementar hoy. Se requiere para la emulación de la rueda del mouse a la tecla de flecha de gnome-terminal en aplicaciones curses. (No confunda eso con el protocolo xterm mouse-event más elegante que nadie usa).

El segundo problema que surgió de este hilo es que mosh no admite un historial útil de desplazamiento hacia atrás. Es cierto que un efecto secundario de poner la terminal en modo de pantalla alternativa sería que el historial de desplazamiento hacia atrás inútil de mosh se volvería inaccesible. Lo considero una característica, no un error. Si más tarde queremos poner mucho trabajo en el diseño de un sistema para agregar un desplazamiento hacia atrás útil, eso sería increíble. Pero esa es una solicitud de función totalmente separada, y no es necesaria para lo que entiendo que es el caso común en el que el usuario simplemente ejecuta screen dentro mosh todos modos. Propongo reabrir el #122 para eso.

Deberíamos arreglar mosh ahora para poner la terminal en modo de pantalla alternativa, con un interruptor de línea de comandos para desactivarlo (como less -X ) para las personas que piensan que el retroceso roto es más importante que una rueda de mouse que funcione.

Anders, está bien, estoy convencido de esto para 1.2.4 si solo significa agregar smcup y rmcup a Terminal::Emulator::open() y Terminal::Emulator::close(). ¿Estaría dispuesto a enviar una solicitud de extracción? (Supongo que queremos que las llamadas terminfo reales permanezcan en src/terminal/terminaldisplayinit.cc).

Considero que la emulación de la rueda del mouse a la tecla de flecha de gnome-terminal es un error horrible. Hay mucha gente que está de acuerdo conmigo: https://bugzilla.gnome.org/show_bug.cgi?id=518405

Desafortunadamente, los desarrolladores de GNOME no están de acuerdo con la interpretación del error, y andersk tampoco. Intentaré convencerte (fútilmente, sospecho) de que es un bicho horrible. La razón por la que la asignación de eventos de la rueda a las teclas de flecha es mala es porque se supone que desplazar la rueda del mouse es una operación _no destructiva_. Mi modelo mental de la rueda del mouse es que se supone que desplazar la rueda solo cambia la vista del búfer de desplazamiento del terminal. Nunca debe alterar el estado del terminal en sí. Desafortunadamente, en muchas situaciones, como clientes de IRC y muchos otros escenarios que se mencionan en el hilo bugzilla de GNOME, el comportamiento de GNOME de emular las teclas de flecha de hecho resulta en la pérdida permanente del estado del búfer de entrada de una aplicación cada vez que se golpea la rueda del mouse. Por ejemplo, digamos que estoy escribiendo una línea cuando golpeo la rueda del mouse. La rueda del mouse activa de manera exasperante una pulsación de flecha del teclado, que borra la línea que estaba escribiendo. Arreglar las aplicaciones individuales es problemático dada la gran cantidad de aplicaciones que presentan el problema.

El hecho de que mosh no pueda usar el modo de pantalla alternativa ha sido una gran bendición para mí, porque significa que los eventos accidentales de la rueda del mouse no destruyen el estado del cliente de IRC desde dentro de mosh. Dado que todo el uso de mi cliente IRC ocurre dentro de mosh, esta característica (¿no intencionada?) de mosh neutraliza por completo el error subyacente de GNOME para mí. Me entristecería mucho ver desaparecer este comportamiento.

Si elige implementar esta idea completamente demente, por favor (como sugiere andersk) proporcione un interruptor para desactivarla. No es que prefiera el scrollback roto. Es que odio la pérdida de datos por encima de todas las demás consideraciones, y las teclas de flecha no deseadas provocan la pérdida de datos.

(Con respecto al segundo problema de este error, en el que mosh provoca la pérdida de datos del contenido de desplazamiento hacia atrás, por supuesto, apoyo firmemente cualquier esfuerzo por cambiar mosh para preservar los datos de desplazamiento hacia atrás. No hay nada en el mundo que sea más importante que evitar la pérdida de datos).

davidjao: gnome-terminal ya proporciona una casilla de verificación (Editar → Preferencias de perfil → Desplazamiento → Usar pulsaciones de teclas para desplazarse en la pantalla alternativa) para deshabilitar por completo la emulación de teclas de flecha. Pero nadie está en desacuerdo en que también podría haber un cambio de línea de comando para aquellos que necesitan solucionar esto por aplicación por alguna razón.

Esta casilla de verificación solo existe en Ubuntu y derivados de Ubuntu. No está incluido en el gnome-terminal ascendente y otras distribuciones como Fedora, Debian, Arch, etc. no lo proporcionan. Por supuesto que puedes parchearlo tú mismo, pero eso es un dolor.

Entiendo que todos estamos de acuerdo en que es deseable un cambio de línea de comandos, pero me preocupa que se omita o se considere sin importancia. Por eso quería comentar por qué es importante.

Gracias a todos, la opción --no-init funciona perfectamente para deshabilitar el modo de pantalla alternativa para aquellos de nosotros que no lo queremos.

Con el ánimo de mantener la documentación actualizada, ¿podríamos mencionar en la página del manual (en la sección VARIABLES DEL ENTORNO) que la variable MOSH_NO_TERM_INIT inhibe smcup/rmcup?

Para mí, la opción "--no-init" no resuelve el problema de desplazamiento hacia atrás con la rueda del mouse.

"--no-init" está completamente roto aquí con el terminal XFCE: una parte de la salida se olvida en el historial y la barra de desplazamiento se actualiza de manera inconsistente. ¿Por qué mosh no puede simplemente comportarse como lo hace ssh? Ser obstinado está bien, pero también sería bueno beneficiarse de las mejoras de red sin tener que tomar diferentes decisiones de emulación de terminal al usuario.

los

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

la solución funciona. ¿Cuál sería el comando equivalente para usar tmux en lugar de screen y garantizar que no queden procesos tmux cuando me desconecto?

Gracias.

En realidad hablé demasiado pronto. La solución alternativa de la pantalla tiene problemas. Si lo uso en dos ventanas de terminal separadas, una después de la otra, la segunda ventana secuestra la pantalla de la primera ventana. Sería genial tener scrollback para eliminar la necesidad de esto. Gracias.

@dtenenba , este no es un foro de soporte para tmux y screen. Lea las páginas de manual ( tmux(1) , screen(1) ), especialmente las partes sobre la opción -d a tmux attach-session , y la -d , -r , -x opciones a screen .

Me gustaría llamar la atención sobre este artículo . Describe una configuración simple y agradable que combina mosh y tmuc lo que da como resultado un historial de desplazamiento hacia atrás (con el mouse) en terminales que admiten el mouse xterm. En OS X, eso es iTerm o incluso Terminal.app con complemento easySIMBL y MouseTerm .

¿Parece que esto todavía no está realmente implementado? ¿Ejecutar mosh -n --no-init todavía deshabilita el desplazamiento para mí? (Mac OS X con Terminal).

--no-init solo existe para restaurar el comportamiento anterior a 1.2.4 de no deshabilitar la barra de desplazamiento de la terminal, para apaciguar a aquellos que creían que se estaba perdiendo la funcionalidad. Mosh nunca ha podido garantizar que el búfer de desplazamiento de la terminal se llene realmente con algo, y mucho menos con algo útil, debido a la forma en que optimiza los deltas de cuadros en su protocolo de sincronización de estado. Ver #122.

Sería muy bueno si mosh admitiera el desplazamiento hacia atrás. Estoy usando mysql en el servidor y la salida de Describe es más larga que la pantalla, por lo que me es imposible ver la parte superior. Oh, bueno, de vuelta a ssh, supongo.

En mysql cli, puede hacer pager less y la salida se redirigirá a less en lugar de imprimirse directamente.

@tsuna ¡Gracias! ese comando es genial

alguna esperanza de que esto se arregle algun dia?

El indicador --no-init a veces funciona, a veces no. Esperamos ver un soporte de desplazamiento hacia atrás nativo con Mosh.

Último iTerm2 en macOS Sierra 10.12.5

Sí, esto es un gran problema para mí. Usaré esto una vez que se solucione este obstáculo obvio.

Realmente no estoy seguro de qué se trata todo este alboroto, si desea desplazarse hacia atrás, use screen o tmux, son herramientas maravillosas, y usarlas adecuadamente le permitirá hacer MUCHO más que intentar incorporar más funciones en mosh. La filosofía de Unix para herramientas, hacer una cosa bien, se ilustra PERFECTAMENTE en este caso. https://en.wikipedia.org/wiki/Unix_philosophy

Acabo de probar esto en mi máquina local conectándome a otra máquina. Me conecto usando mosh, me vuelvo a conectar a tmux usando -- tmux attach como argumento de la cadena de conexión, y me vuelvo a conectar a mi sesión con la capacidad de desplazarme hacia atrás a través del historial, desplazar mi "barra de ventana" de tmux para ir a diferentes paneles, en resumen, todo lo que la gente ha estado pidiendo arriba SIN ningún cambio en mosh.

Si se está desplazando hacia atrás a través de los comandos anteriores, probablemente esté usando solo mosh o esté en la pantalla. Hace esto ya sea que se conecte a través de SSH o mosh, porque usa la "pantalla alternativa" en sí. Me gusta la pantalla, pero tmux es mucho mejor para múltiples comandos y sesiones, y maneja el desplazamiento y el historial de una manera mucho más sensata, en mi opinión.

@ dragon788 es bueno escuchar eso. Pero, ¿puedes desplazarte hacia arriba con el mouse?
porque mencionaste que puedes desplazarte usando la "barra de ventana" que yo
No creo que sea un problema aquí.

El sábado 21 de octubre de 2017 a las 6:26 a. m., dragon788 [email protected] escribió:

Realmente no estoy seguro de qué se trata todo este alboroto, si quieres usar scrollback
screen o tmux, son herramientas maravillosas, y usarlas apropiadamente
te permite hacer MUCHO más que intentar incluir más funciones en mosh. el unix
filosofía para las herramientas, haz una cosa bien, se ilustra PERFECTAMENTE en este
caso. https://en.wikipedia.org/wiki/Unix_philosophy

Acabo de probar esto en mi máquina local conectándome a otra máquina. I
conéctese usando mosh, vuelva a conectarse a tmux usando -- tmux adjuntar como el
argumento de la cadena de conexión y vuelvo a conectarme a mi sesión con
la capacidad de desplazarse hacia atrás a través de la historia, desplazar mi tmux "barra de ventana" para
ir a diferentes paneles, en resumen, todo lo que la gente ha estado pidiendo
arriba SIN ningún cambio en mosh.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/mobile-shell/mosh/issues/2#issuecomment-338336608 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ABhWeSFAPBiXYl3BA5W4lb43V_fw2f_Lks5suR4HgaJpZM4ABSOa
.

>

Eduardo D. Bergavera, Jr.
Administrador de Linux
Correo electrónico: [email protected]
OpenID: https://launchpad.net/~edbergavera
Github: https://github.com/edbergavera

El alboroto no tiene nada que ver con la falta de funcionalidad de desplazamiento hacia atrás. El problema es que en el modo de pantalla alternativa, los eventos de la rueda del mouse destruyen el búfer de comando actual porque un evento de la rueda del mouse se interpreta como una tecla de flecha. Esto es devastador porque significa que el desplazamiento accidental conduce a la pérdida de datos.

Su sugerencia parece ser "no use la pantalla GNU", pero este consejo es insostenible por muchas razones obvias.

@edbergavera Me estoy desplazando hacia atrás usando el historial tmux a través del modo de copia (que conserva la salida del comando en el control remoto, que en mi opinión, ya que es donde se ejecutan los comandos y donde realmente importa es dónde debería estar el historial). Creo que puede usar la rueda de desplazamiento del mouse si tiene un complemento para tmux que interpreta los códigos de escape de la rueda de desplazamiento como una señal para ingresar al modo de copia y desplazarse, o simplemente puede Prefijo + [ o lo que sea que enlace para ingresar al modo de copia y luego desplácese con el mouse asumiendo que su terminal no está capturando los eventos y los reenvía intactos al servidor. Prefijo + Esc es otro equivalente.

¿Qué pasa con una bandera que dice cuánto historial cargar al inicio (como tail -n)?

Me entristece que esto todavía esté abierto, he estado revisando cada dos años para ver si se ha resuelto el soporte de desplazamiento nativo, pero hasta entonces, lamentablemente, no puedo usar esto.

Para aclarar, solo me importa volver a conectarme de manera confiable después de una interrupción de la red sin que terminen los prorams en el host remoto.

No puedo creer que esto nunca se arregle :( Es una pesadilla. ssh muere. mosh no se puede usar.

Mosh instalado para usarlo en el trabajo con una conexión 4G inestable. Parece que funciona muy bien en conexiones deficientes, pero las funciones de desplazamiento que faltan hacen que no funcione para mí. Lo desinstalé instantáneamente porque prefiero volver a iniciar sesión en SSH varias veces al día que perderme esta función crítica.

@ mr-propre Realmente es un hecho básico de usabilidad. Lo uso para conectarme a los clústeres de Spark porque ssh falla y luego uso la pantalla con CTRL-A, Escape y luego página arriba/abajo para desplazarme, pero es muy irritante y el búfer es demasiado pequeño.

No estoy seguro de si ya se mencionó aquí, pero si está afectado por este problema, es posible que desee echar un vistazo a Eternal Terminal como alternativa.

Amigos, ¿se dan cuenta de que pueden ajustar la cantidad de desplazamiento hacia atrás que guarda la pantalla y tmux?

Este es un problema resuelto para la mayoría de las personas (que usan screen/tmux, o incluso menos, en el lado del servidor). Es probable que Mosh no obtenga su propio protocolo de retroceso remoto en el corto plazo.

Soy consciente. Simplemente apesta que el cliente no maneje esto como cualquier otro
uno del que he oído hablar.

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

El martes 13 de agosto de 2019 a las 12:54 p. m. Keith Winstein [email protected]
escribió:

Amigos, se dan cuenta de que pueden ajustar la cantidad de desplazamiento hacia atrás en esa pantalla
y tmux guardar?

Este es un problema resuelto para la mayoría de las personas (que usan screen/tmux, o
menos aún, del lado del servidor). Mosh probablemente no obtenga lo suyo.
protocolo de retroceso remoto en el corto plazo.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/mobile-shell/mosh/issues/2?email_source=notifications&email_token=AAAKJJKV4Y2R4PB2E6UWYL3QEMGPNA5CNFSM4AAFEONKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4GZK3I#issuecomment-391709,8
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAAKJJMBSF2QEQUAEBR5X5TQEMGPNANCNFSM4AAFEONA
.

Este problema es realmente molesto, hasta que aprende a usar tmux. Entonces ya no es un problema.

Lo siento pero no estoy de acuerdo. Desde mi punto de vista, tener que usar tmux es un poco complicado. Si quisiera usar tmux, sería lo suficientemente bueno con ssh + tmux.

En realidad, tengo curiosidad por saber cuál es la ventaja de "mosh+tmux" frente a "ssh+tmux". ¿Lo que la gente piensa?

La mayoría de los mismos beneficios de mosh todavía se aplican cuando se usa tmux:

• Conectividad perfecta cuando su cliente cambia de red o su máquina cliente sale de un estado suspendido/hibernado
• eco local
• mejor manejo de control-C

Probé tmux y screen pero no solucionan el mayor problema que tengo con mosh: no puedo pegar el código de Python en la terminal. Haré un problema separado: https://github.com/mobile-shell/mosh/issues/1066

Yo mismo, no me opongo a usar tmux, pero el desplazamiento usando tmux es lento ya que requiere esperar a que el servidor remoto envíe los contenidos de pantalla actualizados. Uno de los principales puntos de venta de Mosh es que proporciona una mejor interactividad que ssh en redes lentas o poco confiables. Sin embargo, cuando se trata de desplazamiento hacia atrás, confiar en tmux proporciona una interactividad peor que el desplazamiento hacia atrás local.

¿Qué tan difícil sería agregar un retroceso a mosh? ¿Qué está involucrado?

pero el desplazamiento con tmux es lento, ya que requiere esperar a que el servidor remoto envíe los contenidos de pantalla actualizados

Si mosh alguna vez aprende a retroceder, me imagino que tendría que hacer lo mismo, así que no entiendo muy bien esta queja.

¿Por qué tendría que hacer lo mismo? En principio, Mosh debería poder mantener una copia local del búfer de desplazamiento hacia atrás. Supongo que podría haber problemas si algo está enviando spam a la terminal lo suficientemente rápido como para que el cliente no reciba todo el texto (ya que Mosh acelera intencionalmente las actualizaciones de pantalla a una velocidad de fotogramas fija). Pero eso tiene solución; Mosh necesitaría algún tipo de algoritmo para sincronizar los contenidos de desplazamiento hacia atrás con el servidor, idealmente con una prioridad más baja que las actualizaciones de pantalla.

Es 2020 y el número 2 aún está abierto... vaya...

Realmente no estoy seguro de qué se trata todo este alboroto, si desea desplazarse hacia atrás, use screen o tmux, son herramientas maravillosas, y usarlas adecuadamente le permitirá hacer MUCHO más que intentar incorporar más funciones en mosh. La filosofía de Unix para herramientas, hacer una cosa bien, se ilustra PERFECTAMENTE en este caso. https://en.wikipedia.org/wiki/Unix_philosophy

@ dragon788 en todo caso, esto muestra las desventajas de _no_ seguir la filosofía de Unix. Mosh rompe la filosofía de Unix al hacer mucho más que una sola cosa, por lo que termina en la posición en la que es un emulador de terminal por derecho propio, pero uno muy limitado sin soporte de desplazamiento hacia atrás.

Esto está bien para un emulador de terminal real (demonios, uso st y pruebo otros emuladores de terminal sin desplazamiento hacia atrás), pero cuando Mosh lo hace, rompe el desplazamiento hacia atrás existente, lo que va más allá de simplemente no admitir el desplazamiento hacia atrás. Ya estoy usando tmux para albergar la sesión de Mosh, entonces, ¿por qué debo iniciar otra sesión de tmux en el extremo del servidor también?

Ahora, el _servidor_ (y ese es _todos los servidores a los que desea conectarse) debe tener tmux o similar instalado solo para evitar la _interrupción_ del desplazamiento hacia atrás de Mosh (no solo su falta de soporte), entonces, ¿cómo sigue eso? la filosofía Unix, exactamente?

ssh establece el estándar aquí. Mosh viola ese estándar, lo que requiere la adición de una pieza de software completamente nueva que la mayoría de los usuarios no quieren en el servidor, por lo que las personas no usan Mosh tanto como lo harían si admitiera el desplazamiento hacia atrás de la manera que los usuarios esperan porque las alternativas lo admiten. . Hay una fuerte actitud de “no es mi problema” a pesar de que este es un problema muy real para la mayoría de los usuarios de Mosh que limita la cantidad de impacto que el trabajo de los colaboradores de Mosh tiene con el proyecto. Obviamente, el código abierto se trata de poner su dinero donde está su boca y agregar lo que necesita. No estoy en condiciones de agregar esta función, por lo que yo y muchos otros como yo no usamos Mosh a menos que sea absolutamente necesario. Espero que alguien de un paso al frente y agregue esta función porque es una brecha importante en Mosh como un proyecto de código abierto y su disponibilidad aumentará drásticamente la adopción de Mosh y hará que muchos usuarios estén muy contentos.

La forma en que cerró el boleto significa que nadie va a dar un paso al frente y hacer esa contribución, lo cual es desafortunado. Lo mínimo que podría hacer por su comunidad es dejar de pasar la pelota y hacer mal uso de la filosofía de Unix y simplemente admitir que no tiene ganas de agregarlo y dejar que alguien más se involucre y lo haga. “No es mi problema” puede hacerte sentir mejor por tener menos tickets abiertos, pero esta actitud socava el proyecto y sus usuarios. Este ticket tiene 76 comentarios. ¿Cuántas de sus otras entradas tienen 76 comentarios? Le sugiero que piense por qué contribuye al código abierto y si valora a su comunidad en absoluto con esta actitud.

Abra este ticket y al menos deje que alguien más se presente y agregue esta capacidad esencial.

Realmente no estoy seguro de qué se trata todo este alboroto, si desea desplazarse hacia atrás, use screen o tmux, son herramientas maravillosas, y usarlas adecuadamente le permitirá hacer MUCHO más que intentar incorporar más funciones en mosh. La filosofía de Unix para herramientas, hacer una cosa bien, se ilustra PERFECTAMENTE en este caso. https://en.wikipedia.org/wiki/Unix_philosophy

@ dragon788 en todo caso, esto muestra las desventajas de _no_ seguir la filosofía de Unix. Mosh rompe la filosofía de Unix al hacer mucho más que una sola cosa, por lo que termina en la posición en la que es un emulador de terminal por derecho propio, pero uno muy limitado sin soporte de desplazamiento hacia atrás.

Esto está bien para un emulador de terminal real (demonios, uso st y pruebo otros emuladores de terminal sin desplazamiento hacia atrás), pero cuando Mosh lo hace, rompe el desplazamiento hacia atrás existente, lo que va más allá de simplemente no admitir el desplazamiento hacia atrás. Ya estoy usando tmux para albergar la sesión de Mosh, entonces, ¿por qué debo iniciar otra sesión de tmux en el extremo del servidor también?

Ahora, el _servidor_ (y ese es _todos los servidores a los que desea conectarse) debe tener tmux o similar instalado solo para evitar la _interrupción_ del desplazamiento hacia atrás de Mosh (no solo su falta de soporte), entonces, ¿cómo sigue eso? la filosofía Unix, exactamente?

Esta. Tanto esto.

Traigamos esta conversación de vuelta desde la órbita terrestre baja, muchachos. La razón por la que Mosh no admite el desplazamiento hacia atrás no tiene nada que ver con la filosofía. Tampoco tiene nada que ver con si este ticket está abierto o cerrado; ya hay un ticket abierto para el desplazamiento hacia atrás, y no es este ticket, que era sobre el modo de pantalla alternativa. Tiene todo que ver con el tiempo limitado del desarrollador. Si ha leído el documento de Mosh, comprenderá cómo la forma en que Mosh prioriza la interactividad hace que la entrega de desplazamiento hacia atrás utilizable sea un desafío, por lo que quedó fuera de la implementación inicial y nadie ha tenido tiempo de agregarlo desde entonces. Si tuviéramos tiempo infinito para trabajar en Mosh, una función de desplazamiento hacia atrás probablemente sería una prioridad. Nadie le impide desarrollar esta funcionalidad si está interesado y, como siempre, es probable que se acepte una solicitud de incorporación de cambios bien diseñada e implementada. Pero quejarse de un tema cerrado no hará que eso suceda más rápido.

@andersk Creo que es esta prioridad de la interactividad la que se ve como una desviación de la filosofía de Unix. Mosh hace tanto conexiones que no mueren (una característica que realmente me gustaría) como interactividad (una característica cuyo precio, un desplazamiento hacia atrás que no es un flujo ASCII completo y puro, no estoy dispuesto a pagar). Lo que la gente parece estar pidiendo es la confiabilidad sin la interactividad, ya que piensan que el modo de pantalla alterna es un precio demasiado alto a pagar.

Pragmáticamente, no estoy realmente interesado en si Mosh sigue la filosofía UNIX o no; todo lo que sé como usuario es que es una gran pieza de software para _usar_, excepto por este defecto evidente.

No estoy aquí para rogarle al autor que agregue la función de forma gratuita, entiendo que es lo que es y no me deben código ni tiempo ni esfuerzo ni nada.

Mi comentario fue _solo_ criticando la afirmación de que (parafraseando) "Mosh no debería hacer esto porque va en contra de la filosofía de Unix"; mi respuesta a eso es que la única razón por la que Mosh tiene que hacer esto en primer lugar es exactamente _porque_ ya va en contra de la filosofía de Unix. No estoy juzgando si eso es bueno o malo, no sé cuáles fueron todas las compensaciones y qué _no_ seguir la filosofía de Unix compró a Mosh.

Mientras tanto, mi solución es simplemente no usar Mosh. Espero estar en condiciones de establecer una recompensa en un futuro cercano ahora que estoy al tanto de Mosh nuevamente y de lo que se interpone en mi camino. Más allá de eso, seguiré usando SSH y respetuosamente le haré saber al autor que esto es lo único que se interpone en mi camino para usar Mosh (a la gente generalmente le importa que algunas personas no se beneficien de su trabajo hasta que esas personas sean groseras) .

@rjurney Estoy bastante seguro de que la persona que cita la filosofía de Unix no es el autor. No hay razón para ser tan duramente crítico.

El autor también tiene un problema abierto en scrollback . Está bloqueado porque la discusión prácticamente ha terminado. Todos lo queremos, pero ninguno de nosotros lo tendrá hasta que algunos de nosotros lo implementemos. Pero el tema está abierto. Todo se reduce a todos nosotros ahora, no solo al creador.

Voy a desbloquear el problema abierto sobre el desplazamiento hacia atrás, ya que tuvo la oportunidad de enfriarse. Sin embargo , evite comentar sobre ese problema (o este problema) si no hay nada nuevo que agregar. Hay botones de "reacción" en github que se pueden usar para expresar su interés (que no envían spam a todo el hilo), y los comentarios como "+1" no son útiles. Sabemos que este es un problema muy importante para algunas personas y que ejecutar screen/tmux en el servidor no siempre es una solución conveniente o aceptable.

Los comentarios sobre la filosofía de Unix son interesantes, pero definitivamente __fuera de tema__ para este rastreador de problemas de github. (Sin embargo, le invitamos a unirse a nuestro canal IRC #mosh en freenode para hablar sobre este tipo de cosas).

No estoy seguro de si ya se mencionó aquí, pero si está afectado por este problema, es posible que desee echar un vistazo a Eternal Terminal como alternativa.

Eternal Terminal no tiene un paquete binario para centos 7, recientemente dediqué horas a compilarlo manualmente y finalmente me di por vencido.