Mosh: Scrollback e tela alternativa (era: Use tela alternativa em smcup/rmcup )

Ou talvez o cliente deva sempre colocar o terminal real no modo de tela alternativa, pela mesma razão que os aplicativos de maldição fazem - o histórico de rolagem que ele gera na tela principal não é particularmente útil de qualquer maneira.

Em uso normal (como digitação linha por linha no shell), a rolagem do terminal real será um pouco útil. Não tenho certeza se quero abrir mão disso completamente, embora talvez o usuário fique irritado com o fato de impressões maiores estarem apenas parcialmente na rolagem.

Olá, gostaria de saber se você tem algum plano sobre este assunto? Acho que o mosh deve funcionar como o ssh, que entrará no modo smcup quando o aplicativo remoto solicitar. Acho muito chato quando uso o vim para abrir um arquivo grande e deixa muitos scrollbacks.

Aqui está a solução proposta atual:

(a) mosh-client coloca o terminal na tela alternativa o tempo todo

(b) o mosh-server interpreta o SMCUP/RMCUP da maneira que o xterm faz, então o "vim" das pessoas continua a funcionar da mesma forma que no xterm (ou na tela com altscreen habilitada)

(c) pegamos control-pgUp e control-PgDown para nossos próprios fins desonestos (fornecendo a rolagem adequada).

Parece razoável para mim. Propus as seguintes modificações para (c):

• também pegamos Ctrl-Up e Ctrl-Down (já que é isso que Ctrl-wheel envia no gnome-terminal)
• mas não pegamos nenhuma tecla para rolar enquanto o aplicativo interno está dentro de uma tela alternativa.

Eu entendi corretamente que o plano aqui é fornecer rolagem semelhante ao que um terminal regular fornece? Ou seja, se eu executar um comando com muita saída, posso rolar para trás de forma confiável com as barras de rolagem do meu terminal para ver tudo o que foi gerado por esse comando? Essa é uma questão de usabilidade muito importante para mim. Obrigado!

Sim, Scott, esse é o plano, embora você não possa usar as barras de rolagem do seu terminal local. Por enquanto, você pode usar screen ou tmux no lado do servidor para obter esse recurso.

Essa é uma boa ideia. É possível suportar a roda do mouse também?

Sim, se fizermos isso com a emenda de Anders, ela apoiará a roda do mouse.

Acordado. Este é o único problema significativo com Mosh no momento. É o único problema que manchou minha experiência.

+1

+1

Eu concordo. Eu prefiro ler uma página inteira de lixo PGP :)

Eu concordo. Eu prefiro ler uma página inteira de lixo PGP :)

+1

(eu... simplesmente... não resisti...)

+1 para isso

+1 para corrigir a rolagem no mosh (showstopper para mim)

-2 Mkaisi

+1, às vezes cat um arquivo no servidor para copiá-lo localmente e não oferecer suporte a rolagem para trás impede isso.

+1 para corrigir o scrollback (o único problema real com o mosh até agora).

+1 para corrigir a rolagem, -1 para mkaysi, eu me pergunto por que o mosh não pode se comportar como ssh nisso. Eu tenho diretórios enormes que "ls" o dia todo, então tenho que usar ssh.

Como shell seguro SSH, mas permite mobilidade e mais responsivo e robusto.

@ubershmekel : Você pode usar screen ou tmux no lado remoto para rolagem. Ou simplesmente ls | less .

Eu me pergunto por que o mosh não pode se comportar como ssh nisso.

Estou feliz que você perguntou. :)

O SSH está simplesmente transmitindo um fluxo de bytes do servidor para o cliente; não importa o que os bytes representam. Assim, o terminal local (XTerm ou sei lá) coloca todo o histórico em ordem e pode rolar.

Por outro lado, o Mosh rastreia o estado _current_ do terminal no lado _server_ e então sincroniza essa representação entre cliente e servidor. Esta é a principal decisão de design que permite os recursos exclusivos do Mosh - roaming, eco local e melhor utilização de conexões ruins. Por outro lado, complica algumas coisas que são simples no mundo do SSH de carregar bytes em ordem.

Para suportar a rolagem, precisaremos adicionar histórico a esse objeto de estado do terminal e aumentar o protocolo para que o cliente possa solicitar bits do histórico sob demanda, à medida que o usuário rola. (Sem fazê-lo sob demanda, perdemos uma vantagem importante do Mosh sobre o SSH, que é que os comandos que geram saída serão atualizados em uma "taxa de quadros" fixa em vez de atrasar a conexão.)

Isso é certamente factível, e obviamente é algo que muitas pessoas querem. Mas não é realmente "apenas faça o mesmo que o SSH" e não é uma mudança trivial. Enquanto isso, acho que executar screen ou tmux no lado do servidor é uma boa solução (e tem muitas outras vantagens).

Devo dizer que rodar screen no servidor era exatamente o que eu esperava evitar com o mosh. Isso é o que eu estava fazendo com o SSH quando estava com medo de que a conexão fosse interrompida por causa da mudança de IP ou algo assim. Com o mosh, eu esperava poder executá-lo e todo o resto seria resolvido automaticamente.

Você poderia até integrar o mosh com a tela. :-)

@kmcallister

Eu me pergunto se o mosh poderia criar um modo alternativo onde ele pula toda a magia do pty e apenas age como o ssh normal.

É claro que isso removeria o benefício da otimização da latência, mas acredito que muitas pessoas (pelo menos eu) estão interessadas apenas na persistência da conexão. Nesse modo, uma exibição seria restaurada simplesmente reproduzindo os últimos n bytes incondicionalmente. Manter o controle dos deslocamentos de buffer local/remoto para acionar a quantidade certa de reprodução nos momentos certos deve ser bastante fácil, então ...

Com o mosh, eu esperava poder executá-lo e todo o resto seria resolvido automaticamente.

Você pode correr

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

Isso também ajuda com outro problema. Se um mosh-client morrer inesperadamente (digamos, porque a máquina cliente perdeu energia), o mosh-server correspondente ficará inutilmente. Mas executar screen -dR fará com que o outro processo screen saia, matando aquele antigo mosh-server . É claro que você pode tornar isso mais sofisticado com sessões nomeadas screen e tal.

@moe: O que você descreve é ​​factível, mas estou relutante em adicionar modos alternativos ao Mosh que mudam fundamentalmente o princípio de operação. Talvez algo como autossh atenda às suas necessidades?

Tentei usar o Mosh para a persistência da conexão, e nada que li antes de usá-lo me deu uma indicação clara de que era tudo menos um shell comum com um transporte aprimorado. Quando Mosh descartou alguma saída importante, eu não tinha ideia do que estava acontecendo e perdi alguns dias (tempo de calendário, várias horas de tempo real de solução de problemas) olhando para todo o resto porque não me ocorreu que uma ferramenta para conexões persistentes e melhor latência também jogaria fora meus dados. Depois disso, não posso confiar em você, não porque a maneira como o Mosh funciona não seja razoável, mas porque a maneira como é descrita não transmite que você não pode contar com o recebimento da saída completa de qualquer comando. (Suspeito que também não transmita os objetivos que levaram à decisão de fazê-lo funcionar dessa maneira, mas isso não é importante.) No mínimo, as condições para descartar dados devem ter uma posição de destaque onde nenhum novo usuário que leia qualquer coisa sobre Mosh poderia razoavelmente falhar em perdê-lo. Se eu tivesse lido tal aviso antes que minha saída fosse perdida, mesmo que eu não tivesse entendido o aviso, eu teria trocado aqueles dias de agravamento por um momento de "Ah, isso é o que isso significava!"

Não posso concordar com a Polyergic. Eu acho que o site está bem feito e também a interface com os caracteres sublinhados indica bem que há alguma previsão sendo feita. Não tive problemas de não entender o que está acontecendo. A única coisa que me surpreendeu foi que --predict=never ainda não fazia a saída funcionar como eu era usado.

Então, eu talvez apenas pedisse uma troca (eu posso então bash-alias) que transferiria tudo. Ele ainda pode prever.

Então eu vejo três opções aqui:

• previsão + não transferir tudo (útil para links de alta latência e baixa largura de banda)
• previsão + transferência de tudo (útil para links de alta latência e alta largura de banda)
• nenhuma previsão + não transferir tudo (útil apenas para persistência de conexão)

Eu caio em 2. categoria. As ligações transatlânticas para a Europa têm latência de 100ms, mas são rápidas. Eu renomearia mosh para tash neste caso: shell transatlântico. :-)

@kmcallister

Emulando um terminal (tela) dentro de um terminal emulado (mosh), para
para emular a funcionalidade nativa (scrollback) do emulador de terminal envolvente
(xterm, iterm) não resulta e não pode resultar em uma experiência de usuário aceitável.

Esse é o problema subjacente aqui. Claro que nem mosh é o culpado por
30 anos de estagnação no negócio de emulador de terminal, nem pode ser limpo
resolver a situação de onde ele está atualmente na pilha.

Daí minha proposta de um 'modo mudo', como um curativo de curto prazo
para as próximas décadas.

@mitar , não vejo nenhum desacordo entre o que eu disse e o que você disse; reafirmando as coisas sucintamente, o que vejo é isso:

Eu disse: Mosh perde dados de forma inesperada; descrições de Mosh devem definir expectativas para corresponder ao seu comportamento.

Você disse: O site do Mosh é legal; os indicadores de previsão são bons; uma opção para transferir tudo seria bom.

o que estou perdendo? Você viu um aviso claro em algum lugar de que o Mosh não manterá toda a saída de seus comandos?

@moe

Emular um terminal (tela) dentro de um terminal emulado (mosh), para emular a funcionalidade nativa (scrollback) do emulador de terminal envolvente (xterm, iterm) não resulta e não pode resultar em uma experiência de usuário aceitável.

Bem, você poderia descrever o que sobre a experiência do usuário é inaceitável? Esta seria uma informação útil para nós.

Em geral, o mundo dos computadores está cheio de níveis aparentemente ridículos de aninhamento e emulação que, no entanto, proporcionam uma experiência de usuário perfeitamente boa.

@kmcallister

Acima de tudo, o frankenstack não suporta rolagem nativa. Isso é um espetáculo.
'modo de cópia' e hacks de rolagem virtual não são substitutos. Há também uma infinidade de mais sutis
problemas, mas você (como autor de um emulador de terminal) não precisa que eu fale sobre isso. ;)

Como dito, não estou culpando o mosh pela ridícula situação terminal de hoje - isso tem sido terrível
desde muito antes de mosh existir. Dado o escopo do projeto, mosh tinha pouca escolha
do que se agachar nos ombros de gnomos, como todo mundo, e por isso não está se saindo muito mal.

Estou apenas dizendo que com o suposto modo 'burro', o mosh pode funcionar para aqueles de nós que têm
sem problemas com latência e quem gostaria da persistência, mas não pode tolerar uma rolagem quebrada.

Um bandaid em cima do bandaid, por assim dizer.

Apenas até que alguém finalmente pegue um coração e substitua completamente a emulação de terminal VT100 ...

Eu também adoraria ter um modo "burro" que me permitisse usar a rolagem normal na janela do meu terminal para ver o histórico do que fiz antes ou percorrer a saída de um comando grande.

Eu não tenho feito coisas vt100 desde meus dias de BBS, então, por favor, sinta-se à vontade para me bater, mas você não poderia fazer as duas coisas? Toda vez que o estado da tela muda de tal forma que você precisa rolar uma linha para cima da tela, você não pode simplesmente ir até o final e fazer um cr/lf, rolando a linha superior para fora da tela e para a rolagem, em seguida, continue sincronizando o estado da tela como você faz agora?

Claramente, poderíamos perder alguma saída se ficarmos offline e as coisas rolarem para fora da página no servidor, mas eu ficaria bem com isso. Desde que funcione enquanto estou online e interagindo com o shell, ficarei feliz. Eu ficaria ainda mais feliz se você acompanhasse quando as coisas rolavam do topo no lado do servidor que não vimos e rolasse algum tipo de marcador como "mosh: 60 linhas roladas no servidor enquanto você estava offline", mas isso certamente está no território da rodada de bônus. :-)

Para ser claro, estou expressando uma preferência aqui. Se for difícil e entrar em conflito com seus objetivos, tudo bem também. Eu usarei o mosh independentemente, porque o material de conexão sem estado realmente complementa a maneira como eu trabalho. :-) Obrigado por criar isso!

@timspencer Acho que o que você está sugerindo parece razoável, mas pode não ser fácil de implementar. Meu entendimento é que o mosh não acompanha o fluxo de bytes, ele apenas observa o estado atual do terminal e calcula uma diferença com o estado anterior e envia atualizações para o cliente, periodicamente. Se você cat /dev/urandom , a tela será atualizada muito rapidamente, mas o mosh não enviará _tudo_ para o cliente, apenas tirará instantâneos regulares e enviará diffs. Pelo menos é o meu entendimento, não li o código-fonte.

Dito isto, seria realmente incrível ter um modo de streaming em que o mosh apenas transmita tudo e apenas a conexão persistente mais suas coisas de previsão.

Podemos separar isso em duas questões? O problema que relatei é que o mosh deve colocar o terminal no modo de tela alternativa. Esta é uma correção de bug clara que podemos implementar hoje. É necessário para a emulação da roda do mouse para a tecla de seta do gnome-terminal em aplicativos curses. (Não confunda isso com o protocolo de evento de mouse xterm mais sofisticado que ninguém usa.)

A segunda questão que surgiu deste tópico é que o mosh não suporta histórico de rolagem útil. É verdade que um efeito colateral de colocar o terminal no modo de tela alternativa seria que o histórico de rolagem inútil do mosh se tornaria inacessível. Considero isso um recurso, não um bug. Se mais tarde quisermos trabalhar muito para projetar um sistema para adicionar uma rolagem útil, isso seria incrível. Mas essa é uma solicitação de recurso totalmente separada e não é necessária para o que entendo ser o caso comum em que o usuário está apenas executando screen dentro mosh qualquer maneira. Proponho reabrir o nº 122 para isso.

Devemos corrigir o mosh agora para colocar o terminal no modo de tela alternativo, com uma opção de linha de comando para desativá-lo (como less -X ) para pessoas que acham que a rolagem quebrada é mais importante do que uma roda do mouse funcionando.

Anders, ok, estou convencido disso para 1.2.4 se isso significa apenas adicionar smcup e rmcup ao Terminal::Emulator::open() e Terminal::Emulator::close(). Você estaria disposto a enviar um pull request? (Suponho que queremos que as chamadas terminfo reais permaneçam em src/terminal/terminaldisplayinit.cc).

Eu considero a roda do mouse do gnome-terminal para a emulação da tecla de seta um bug horrível. Tem muita gente que concorda comigo: https://bugzilla.gnome.org/show_bug.cgi?id=518405

Infelizmente, os desenvolvedores do GNOME não concordam com a interpretação do bug, e nem parece que andersk. Vou tentar convencê-lo (inutilmente, eu suspeito) que é realmente um bug horrível. A razão pela qual o mapeamento de eventos de roda para teclas de seta é ruim é porque a rolagem da roda do mouse deve ser uma operação _não destrutiva_. Meu modelo mental da roda do mouse é que rolar a roda deve apenas alterar sua visão do buffer de rolagem do terminal. Ele nunca deve alterar o próprio estado do terminal. Infelizmente, em muitas situações, como clientes IRC e muitos outros cenários que são mencionados no tópico GNOME bugzilla, o comportamento do GNOME de emular teclas de seta de fato resulta em perda permanente do estado do buffer de entrada de um aplicativo sempre que a roda do mouse é pressionada. Por exemplo, digamos que estou no meio da digitação de uma linha quando bato a roda do mouse. A roda do mouse aciona irritantemente um pressionamento de seta no teclado, que apaga a linha que eu estava digitando. Corrigir os aplicativos individuais é problemático devido ao grande número de aplicativos que apresentam o problema.

O fato de o mosh falhar em usar o modo de tela alternativa tem sido uma grande bênção para mim, porque significa que eventos acidentais da roda do mouse não destroem o estado do cliente de IRC de dentro do mosh. Como todo o uso do meu cliente de IRC ocorre dentro do mosh, esse recurso (não intencional?) do mosh neutraliza completamente o bug subjacente do GNOME para mim. Eu ficaria muito triste em ver esse comportamento desaparecer.

Se você optar por implementar essa ideia completamente demente, por favor (como andersk sugere) forneça uma opção para desativá-la. Não é que eu prefira rolagem quebrada. É que eu odeio perda de dados acima de todas as outras considerações, e teclas de seta indesejadas resultam em perda de dados.

(Em relação ao segundo problema neste bug, em que o mosh causa perda de dados do conteúdo de rolagem, é claro que apoio fortemente qualquer esforço para alterar o mosh para preservar os dados de rolagem. Não há nada no mundo que seja mais importante do que evitar a perda de dados.)

davidjao: o gnome-terminal já fornece uma caixa de seleção (Editar → Preferências de perfil → Rolagem → Use as teclas para rolar na tela alternativa) para desativar totalmente a emulação das teclas de seta. Mas ninguém discorda de que pode haver uma opção de linha de comando para aqueles que precisam resolver isso por aplicativo por algum motivo.

Esta caixa de seleção existe apenas no Ubuntu e derivados do Ubuntu. Ele não está incluído no gnome-terminal upstream, e outras distribuições como Fedora, Debian, Arch, etc. não o fornecem. Claro que você pode remendar em si mesmo, mas isso é uma dor.

Entendo que todos concordamos que um switch de linha de comando é desejável, mas estou preocupado que ele possa ser deixado de fora ou considerado sem importância. É por isso que eu queria comentar sobre por que é importante.

Obrigado a todos, a opção --no-init funciona perfeitamente para desabilitar o modo de tela alternativo para aqueles que não querem.

No espírito de manter a documentação atualizada, podemos mencionar na página man (na seção ENVIRONMENT VARIABLES) que a variável MOSH_NO_TERM_INIT inibe smcup/rmcup?

Para mim, a opção "--no-init" não resolve o problema de rolagem com a roda do mouse.

"--no-init" está completamente quebrado aqui com o terminal XFCE: alguma parte da saída é esquecida no histórico e a barra de rolagem é atualizada de forma inconsistente. Por que o mosh não pode se comportar como o ssh? Ser opinativo é bom, mas também seria bom se beneficiar das melhorias de rede sem ter diferentes decisões de emulação de terminal forçadas ao usuário.

O

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

solução alternativa funciona. Qual seria o comando equivalente para usar o tmux em vez da tela e garantir que nenhum processo do tmux seja deixado para trás quando eu desconectar?

Obrigado.

Na verdade eu falei cedo demais. A solução alternativa de tela tem problemas. Se eu usá-lo em duas janelas de terminal separadas, uma após a outra, a segunda janela sequestra a tela da primeira janela. Seria ótimo ter scrollback para eliminar a necessidade disso. Obrigado.

@dtenenba , este não é um fórum de suporte para tmux e tela. Leia as manpages ( tmux(1) , screen(1) ), especialmente as partes sobre a opção -d para tmux attach-session , e o -d , -r , -x opções para screen .

Gostaria de chamar a atenção para este artigo . Ele descreve uma configuração simples e agradável combinando mosh e tmuc resultando em um histórico de rolagem de trabalho (com mouse) em terminais que suportam mouse xterm. No OS X, isso é iTerm ou até mesmo Terminal.app com plug-in easySIMBL e MouseTerm .

Parece que isso ainda não está realmente implementado? A execução de mosh -n --no-init ainda desativa a rolagem para mim? (Mac OS X com Terminal.)

--no-init só existe para restaurar o comportamento pré-1.2.4 de não desabilitar a barra de rolagem do terminal, para apaziguar aqueles que acreditavam que a funcionalidade estava sendo perdida. Mosh nunca foi capaz de garantir que o buffer de rolagem do terminal seja realmente preenchido com qualquer coisa, muito menos qualquer coisa útil, devido à maneira como ele otimiza os deltas de quadros em seu protocolo de sincronização de estado. Veja #122.

Seria muito bom se o mosh suportasse o scrollback. Estou usando o mysql no servidor e a saída do describe é maior que a tela, então é impossível para mim ver o topo. Oh bem, de volta ao ssh, eu acho.

No mysql cli você pode simplesmente fazer pager less e a saída será redirecionada para less ao invés de ser impressa diretamente.

@tsuna Obrigado! Esse comando é incrível

alguma esperança de que isso será corrigido algum dia?

O sinalizador --no-init às vezes funciona, às vezes não. Esperamos ver um suporte de rolagem nativo com Mosh.

Último iTerm2 no macOS Sierra 10.12.5

Sim, isso é um grande negócio para mim. Vou usar isso uma vez que esse showtopper óbvio for corrigido.

Realmente não tenho certeza do que se trata, se você quiser rolar para trás, use screen ou tmux, eles são ferramentas maravilhosas, e usá-los adequadamente permitirá que você faça muito mais do que tentar adicionar mais recursos ao mosh. A filosofia unix para ferramentas, fazer uma coisa bem, é PERFEITAMENTE ilustrada neste caso. https://en.wikipedia.org/wiki/Unix_philosophy

Acabei de testar isso na minha máquina local conectando-se a outra máquina. Eu me conecto usando mosh, reconecto ao tmux usando -- tmux attach como o argumento da string de conexão e sou reconectado à minha sessão com a capacidade de rolar para trás no histórico, rolar minha "barra de janela" do tmux para ir para painéis diferentes, resumindo tudo o que as pessoas pediram acima SEM nenhuma alteração no mosh.

Se você está rolando de volta pelos comandos anteriores, provavelmente está usando apenas o mosh ou está na tela. Ele faz isso se você se conectar via SSH ou mosh, porque usa a própria "tela alternativa". Eu gosto da tela, mas o tmux é muito melhor para vários comandos e sessões, e lida com a rolagem e o histórico de uma maneira muito mais sã, na minha opinião.

@dragon788 bom ouvir isso. Mas você pode rolar para cima usando o mouse
porque você mencionou que pode rolar usando a "barra da janela", que eu
acho que não é um problema aqui.

Em sáb, 21 de outubro de 2017 às 6h26 dragon788 [email protected] escreveu:

Realmente não tenho certeza do que se trata, se você quiser usar o scrollback
screen ou tmux, são ferramentas maravilhosas, e usá-las apropriadamente
permitem que você faça muito mais do que tentar colocar mais recursos no mosh. O unix
filosofia para ferramentas, faça uma coisa bem, é PERFEITAMENTE ilustrado neste
caso. https://en.wikipedia.org/wiki/Unix_philosophy

Acabei de testar isso na minha máquina local conectando-se a outra máquina. eu
conecte usando mosh, reconecte ao tmux usando -- tmux attach como o
argumento da string de conexão e estou reconectado à minha sessão com
a capacidade de rolar para trás no histórico, rolar minha "barra de janela" do tmux para
vá para diferentes painéis, enfim tudo o que as pessoas têm pedido
acima SEM nenhuma mudança no mosh.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/mobile-shell/mosh/issues/2#issuecomment-338336608 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/ABhWeSFAPBiXYl3BA5W4lb43V_fw2f_Lks5suR4HgaJpZM4ABSOa
.

>

Eduardo D. Bergavera, Jr.
Administrador Linux
E-mail: [email protected]
OpenID: https://launchpad.net/~edbergavera
Github: https://github.com/edbergavera

O barulho não tem nada a ver com a falta de funcionalidade de rolagem. O problema é que, no modo de tela alternativa, os eventos da roda do mouse destroem o buffer de comando atual porque um evento da roda do mouse é interpretado como uma tecla de seta. Isso é devastador porque significa que a rolagem acidental leva à perda de dados.

Sua sugestão parece ser "não use a tela GNU", mas esse conselho é insustentável por muitas razões óbvias.

@edbergavera Estou rolando de volta usando o histórico do tmux via modo de cópia (que preserva a saída do comando no controle remoto, que IMO, pois é onde os comandos estão sendo executados e onde realmente importa é onde o histórico deve estar). Acredito que você pode usar a roda de rolagem do mouse se tiver um plugin para tmux que interprete os códigos de escape da roda de rolagem como um sinal para entrar no modo de cópia e rolar, ou você pode simplesmente Prefixar + [ ou o que você ligar para entrar no modo de cópia e depois role com o mouse assumindo que seu terminal não está capturando os eventos e os encaminha para o servidor intacto. Prefixo + Esc é outro equivalente.

Que tal um sinalizador informando quanto histórico carregar no início (como tail -n)?

Estou triste que isso ainda esteja aberto, tenho verificado a cada dois anos para ver se o suporte de rolagem nativo foi resolvido, mas até então infelizmente não posso usar isso.

Para esclarecer, eu só me importo com a reconexão confiável após a interrupção da rede sem prorams no host remoto terminando.

Eu não posso acreditar que isso nunca será consertado :( É um pesadelo. ssh morre. mosh não é utilizável.

Instalou o mosh para usá-lo no trabalho com uma conexão 4G instável. Parece que está funcionando muito bem em conexões ruins, mas os recursos de rolagem ausentes o tornam impossível para mim. Desinstalei-o instantaneamente, pois prefiro fazer login novamente no SSH algumas vezes ao dia do que perder esse recurso crítico.

@mr-propre É realmente um fato básico de usabilidade. Eu o uso para me conectar a clusters Spark porque o ssh falha e, em seguida, uso a tela com CTRL-A, Escape e, em seguida, a página para cima / para baixo para rolar, mas é irritante como o inferno e o buffer é muito pequeno.

Não tenho certeza se já foi mencionado aqui, mas se você for afetado por esse problema, dê uma olhada no Eternal Terminal como uma alternativa.

Pessoal - você percebe que pode ajustar a quantidade de rolagem que a tela e o tmux salvam?

Este é um problema resolvido para a maioria das pessoas (que estão usando screen/tmux, ou até menos, no lado do servidor). O Mosh provavelmente não terá seu próprio protocolo de rolagem remota tão cedo.

Estou ciente. É uma merda o cliente não lidar com isso como qualquer outro
um que eu já ouvi falar.

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

Em terça-feira, 13 de agosto de 2019 às 12h54 Keith Winstein [email protected]
escrevi:

Pessoal -- você percebe que pode ajustar a quantidade de rolagem dessa tela
e tmux salvar?

Este é um problema resolvido para a maioria das pessoas (que estão usando screen/tmux, ou
ainda menos, no lado do servidor). Mosh provavelmente não está conseguindo seu próprio
protocolo de rolagem remota em breve.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/mobile-shell/mosh/issues/2?email_source=notifications&email_token=AAAKJJKV4Y2R4PB2E6UWYL3QEMGPNA5CNFSM4AAFEONKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4GZK3I#comment-5209
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AAAKJJMBSF2QEQUAEBR5X5TQEMGPNANCNFSM4AAFEONA
.

Esse problema é realmente irritante - até você aprender a usar o tmux. Então não é mais um problema.

Desculpe mas discordo. Do meu ponto de vista, ter que usar tmux é um pouco complicado. Se eu quisesse usar o tmux, seria bom o suficiente com ssh + tmux.

Na verdade, eu estaria curioso sobre qual é a vantagem de “mosh+tmux” vs “ssh+tmux”?? O que as pessoas pensam?

A maioria dos mesmos benefícios do mosh ainda se aplicam ao usar o tmux:

• Conectividade perfeita quando seu cliente muda de rede ou sua máquina cliente sai de um estado suspenso/hibernado
• eco local
• melhor manuseio de controle-C

Eu tentei tmux e screen, mas eles não corrigem o maior problema que tenho com o mosh: não consigo colar o código Python no terminal. Vou fazer um problema separado: https://github.com/mobile-shell/mosh/issues/1066

Eu mesmo, não me oponho a usar o tmux, mas a rolagem usando o tmux é lenta, pois requer esperar que o servidor remoto envie o conteúdo da tela atualizado. Um dos principais pontos de venda do Mosh é que ele oferece melhor interatividade do que o ssh em redes lentas ou não confiáveis. No entanto, quando se trata de rolagem, confiar no tmux fornece interatividade pior do que a rolagem local.

Quão difícil seria adicionar um rollback ao mosh? O que está envolvido?

mas a rolagem usando o tmux é lenta, pois exige que o servidor remoto envie o conteúdo da tela atualizado

Se o mosh aprender a fazer scrollback, estou imaginando que ele teria que fazer a mesma coisa, então não entendo muito bem essa reclamação.

Por que teria que fazer a mesma coisa? Em princípio, o Mosh deve ser capaz de manter uma cópia local do buffer de rolagem. Suponho que possa haver problemas se algo estiver enviando spam para o terminal rápido o suficiente para que o cliente não receba todo o texto (já que o Mosh intencionalmente limita as atualizações de tela para uma taxa de quadros fixa). Mas isso é solucionável; O Mosh precisaria de algum tipo de algoritmo para sincronizar o conteúdo de rolagem com o servidor, idealmente com uma prioridade menor do que as atualizações de tela.

É 2020 e a edição nº 2 ainda está aberta... oh garoto...

Realmente não tenho certeza do que se trata, se você quiser rolar para trás, use screen ou tmux, eles são ferramentas maravilhosas, e usá-los adequadamente permitirá que você faça muito mais do que tentar adicionar mais recursos ao mosh. A filosofia unix para ferramentas, fazer uma coisa bem, é PERFEITAMENTE ilustrada neste caso. https://en.wikipedia.org/wiki/Unix_philosophy

@dragon788 se alguma coisa, isso mostra as desvantagens de _não_ seguir a filosofia do Unix. Mosh quebra a filosofia Unix fazendo muito mais do que apenas uma coisa, então acaba na posição em que é um emulador de terminal por direito próprio, mas muito limitado sem suporte a rolagem.

Isso é bom para um emulador de terminal real (inferno, eu uso st e tento outros emuladores de terminal sem rolagem), mas quando o Mosh faz isso, ele quebra a rolagem existente, que vai além de simplesmente não suportar rolagem. Eu já estou usando tmux para hospedar a sessão do Mosh, então por que eu deveria iniciar outra sessão de tmux no servidor também?

Agora, o _server_ (e esse é _every_ servidor ao qual você deseja se conectar) precisa ter tmux ou similar instalado apenas para contornar o _breaking_ de rolagem de Mosh (não apenas a falta de suporte para isso), então como é o seguinte a filosofia Unix, exatamente?

ssh define o padrão aqui. O Mosh viola esse padrão, exigindo a adição de um software totalmente novo que a maioria dos usuários não deseja no servidor, então as pessoas não usam o Mosh tanto quanto usariam se ele suportasse a rolagem da maneira que os usuários esperam, porque as alternativas o suportam . Há uma forte atitude de “não é meu problema”, apesar de ser um problema muito real para a maioria dos usuários do Mosh que limita a quantidade de impacto que o trabalho dos contribuidores do Mosh tem no projeto. Obviamente, o código aberto é colocar seu dinheiro onde está sua boca e adicionar o que você precisa. Não estou em condições de adicionar esse recurso, então eu e muitos outros como eu não usamos o Mosh a menos que seja absolutamente necessário. Espero que alguém intensifique e adicione esse recurso porque é uma grande lacuna no Mosh como um projeto de código aberto e sua disponibilidade aumentará drasticamente a adoção do Mosh e deixará muitos usuários muito felizes.

A maneira como você fechou o ticket significa que ninguém vai se apresentar e fazer essa contribuição, o que é lamentável. O mínimo que você pode fazer pela sua comunidade é parar de passar a responsabilidade e usar mal a filosofia Unix e simplesmente admitir que não tem vontade de adicioná-la e deixar que outra pessoa o faça. “Não é problema meu” pode fazer você se sentir melhor por ter menos tickets abertos, mas essa atitude prejudica o projeto e seus usuários. Este bilhete tem 76 comentários. Quantos de seus outros tickets têm 76 comentários? Eu sugiro que você pense por que você contribui para o código aberto e se você valoriza sua comunidade com essa atitude.

Por favor, abra este ticket e, pelo menos, deixe que outra pessoa avance e adicione esse recurso essencial.

Realmente não tenho certeza do que se trata, se você quiser rolar para trás, use screen ou tmux, eles são ferramentas maravilhosas, e usá-los adequadamente permitirá que você faça muito mais do que tentar adicionar mais recursos ao mosh. A filosofia unix para ferramentas, fazer uma coisa bem, é PERFEITAMENTE ilustrada neste caso. https://en.wikipedia.org/wiki/Unix_philosophy

@dragon788 se alguma coisa, isso mostra as desvantagens de _não_ seguir a filosofia do Unix. Mosh quebra a filosofia Unix fazendo muito mais do que apenas uma coisa, então acaba na posição em que é um emulador de terminal por direito próprio, mas muito limitado sem suporte a rolagem.

Isso é bom para um emulador de terminal real (inferno, eu uso st e tento outros emuladores de terminal sem rolagem), mas quando o Mosh faz isso, ele quebra a rolagem existente, que vai além de simplesmente não suportar rolagem. Eu já estou usando tmux para hospedar a sessão do Mosh, então por que eu deveria iniciar outra sessão de tmux no servidor também?

Agora, o _server_ (e esse é _every_ servidor ao qual você deseja se conectar) precisa ter tmux ou similar instalado apenas para contornar o _breaking_ de rolagem de Mosh (não apenas a falta de suporte para isso), então como é o seguinte a filosofia Unix, exatamente?

Este. Tanto isso.

Vamos trazer essa conversa de volta da órbita baixa da Terra, pessoal. A razão pela qual o Mosh não suporta scrollback não tem nada a ver com filosofia. Também não tem nada a ver com se este ticket está aberto ou fechado – já existe um ticket aberto para rolagem, e não é esse ticket, que era sobre o modo de tela alternativa. Tem tudo a ver com o tempo limitado do desenvolvedor. Se você leu o artigo do Mosh, entenderá como o modo como o Mosh prioriza a interatividade torna a entrega de rolagem utilizável um desafio, então ele foi deixado de fora da implementação inicial e ninguém teve tempo de adicioná-lo desde então. Se tivéssemos tempo infinito para trabalhar no Mosh, um recurso de rolagem provavelmente seria uma prioridade. Ninguém está impedindo você de desenvolver essa funcionalidade se você estiver interessado e, como sempre, uma solicitação de pull bem projetada e bem implementada provavelmente será aceita. Mas reclamar de um assunto encerrado não vai fazer isso acontecer mais rápido.

@andersk Acho que é essa prioridade de interatividade que é vista como um desvio da filosofia unix. O Mosh faz tanto conexões que não morrem (um recurso que eu gostaria muito) quanto interatividade (um recurso cujo preço, um scrollback que não é um fluxo ascii completo puro, não estou disposto a pagar). O que as pessoas parecem estar pedindo é a confiabilidade sem a interatividade, pois acham que o modo de tela alternada é um preço muito alto a pagar.

Pragmaticamente, não estou realmente interessado em saber se Mosh segue a filosofia UNIX ou não; tudo o que sei como usuário é que é um ótimo software para _usar_, exceto por essa falha gritante.

Não estou aqui para implorar ao autor para adicionar o recurso de graça, eu entendo que é o que é e não me devem código ou tempo ou esforço ou qualquer coisa.

Meu comentário foi _somente_ criticando a afirmação de que (parafraseando) “Mosh não deveria fazer isso porque vai contra a filosofia Unix”; minha resposta a isso é que toda a razão pela qual o Mosh tem que fazer isso em primeiro lugar é exatamente _porque_ já foi contra a filosofia do Unix. Não estou julgando se isso é bom ou ruim, não sei quais foram todas as trocas e o que _não_ seguir a filosofia Unix comprou o Mosh.

Minha solução nesse meio tempo é simplesmente não usar o Mosh. Espero estar em posição de estabelecer uma recompensa em um futuro próximo, agora que estou ciente de Mosh novamente e do que está no caminho para mim. Além disso, vou continuar usando o SSH e respeitosamente informar ao autor que essa é a única coisa que me impede de usar o Mosh (as pessoas geralmente se importam que algumas pessoas não estejam se beneficiando de seu trabalho até que essas pessoas sejam rudes) .

@rjurney Tenho certeza de que a pessoa que cita a filosofia Unix não é o autor. Não há razão para ser tão duramente crítico.

O autor também tem um problema aberto na rolagem . Está bloqueado porque a discussão está praticamente encerrada. Todos nós o queremos, mas nenhum de nós o terá até que alguns de nós o implementemos. Mas a questão está aberta. Isso se resume a todos nós agora, não apenas ao criador.

Vou desbloquear a questão aberta sobre o scrollback, já que teve a chance de esfriar. No entanto , evite comentar sobre esse problema (ou esse problema) se não houver nada de novo a acrescentar. Existem botões de "reação" no github que podem ser usados ​​para expressar seu interesse (que não envia spam para todo o tópico), e comentários como "+1" não são úteis. Sabemos que esta é uma questão muito importante para algumas pessoas e que rodar screen/tmux no servidor nem sempre é uma solução conveniente ou aceitável.

Comentários sobre a filosofia unix são interessantes, mas são definitivamente __off-topic__ para este rastreador de problemas do github. (No entanto, você está convidado a se juntar ao nosso canal #mosh IRC no freenode para discutir essas coisas).

Não tenho certeza se já foi mencionado aqui, mas se você for afetado por esse problema, dê uma olhada no Eternal Terminal como uma alternativa.

O Eternal Terminal não possui um pacote binário para o centos 7, recentemente passei horas para compilar manualmente e desisto finalmente.