Mosh: Mecanismo para permitir que el servidor remoto envíe mensajes al cliente

Creado en 29 sept. 2014  ·  7Comentarios  ·  Fuente: mobile-shell/mosh

Realmente me encantaría una forma de permitir que el servidor remoto envíe mensajes cortos al cliente, donde mosh pueda luego pasarlos a un programa externo. El caso de uso aquí es que uso mosh para conectarme a irssi, y realmente quiero alguna forma de que irssi me notifique sobre los aspectos más destacados, pero como se está ejecutando de forma remota, no puede hacerlo. Pensé que Mosh podría definir alguna secuencia de escape que acepte mensajes hasta una longitud específica (algo corto pero no irrazonablemente corto, como quizás 512 o 1024 bytes), y garantiza la entrega (en secuencia) al cliente, similar a cómo maneja los eventos del teclado . En el lado del cliente, se puede usar una bandera para indicar un programa externo que será llamado con cada mensaje (ya sea llamado una vez por mensaje, o quizás invocado en la conexión y los mensajes pasados ​​a través de una tubería, usando algún marco (como byte recuento, nueva línea, mensaje, nueva línea).

Usando este mecanismo, podría escribir un script para irssi que imprima esa secuencia de escape en la terminal, junto con un blob JSON que contenga información sobre el resaltado, y podría escribir un programa en el lado local que muestre notificaciones de OS X para los mensajes .

En teoría, podría hacer todo esto para una conexión SSH, pero debido a cómo mosh maneja la pantalla, no puedo confiar en que ese tipo de cosas funcione para mosh (especialmente porque no sé cómo reacciona mosh a escapes desconocidos).

Comentario más útil

Esto también afecta la integración de shell en iTerm2 (https://iterm2.com/shell_integration.html).

Todos 7 comentarios

Me pregunto si puedo reutilizar algunos de los escapes OSC . La pregunta es si mosh realmente considera que alguno de ellos es algo que debe transmitir siempre, como el teclado, o si solo envía escapes OSC que sabe cómo sincronizar con la sincronización de estado (como el título de la ventana). Porque este último no es aceptable para notificaciones. Además, en una prueba rápida, limita el escape del título de la ventana a solo 255 caracteres, que es un poco más corto de lo que me gustaría para fines de notificación (realmente me gustaría admitir la longitud completa de un mensaje de IRC allí, que IIRC suele tener un poco más de 400 caracteres, e idealmente tendría espacio para un contenedor JSON).

Después de la prueba, mosh sincroniza el estado actual del título de la ventana, en lugar de simplemente transmitir todos los escapes de OSC. No es sorprendente. Dudo que en este momento haya algún escape OSC que considere valores de transmisión obligatoria.

No siento que esto esté realmente dentro del alcance de mosh, pero me encantaría tener esta función.

Si todo lo que hizo Mosh fue elegir alguna secuencia OSC no utilizada y tratarla como una secuencia de transmisión obligada (y documentarla), entonces podría manejar el resto con un programa contenedor. Pero necesito algo que esté garantizado para ser entregado.

Aunque se me ocurre, también necesito poder perforar tmux con cualquier secuencia que sea. No sé cómo maneja tmux los escapes de OSC desconocidos.

A tmux no le importa qué secuencias de escape envíe, siempre que las envuelva correctamente:

printf "\033Ptmux;\033%s\033\\" your_escape_sequence_here_whatever_it_may_be

Esto también afecta la integración de shell en iTerm2 (https://iterm2.com/shell_integration.html).

Esto también afecta el seguimiento del directorio emacs-libvterm (# 1122) y probablemente el seguimiento del directorio emacs en general. No son solo los OSC especiales / indefinidos los que deberían transmitirse. Hay muchos OSC definidos (como OSC 51 en el caso de emacs) que deben transmitirse.

Creo que la forma en que emacs e iTerm2 usan las secuencias de escape es probablemente muy similar.

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

brandonkal picture brandonkal  ·  7Comentarios

Intensity picture Intensity  ·  7Comentarios

cshei picture cshei  ·  5Comentarios

pravi picture pravi  ·  5Comentarios

unphased picture unphased  ·  5Comentarios