Primeiros caracteres do comando repetidos no visor ao concluir


21

Os dois primeiros caracteres foram repetidos enquanto eu uso Tabpara concluir. Na captura de tela abaixo, cdé repetida.

insira a descrição da imagem aqui

Eu tentei rxvt-unicdoe, xterm, terminator. Todos esses emuladores de terminal têm esse problema.

Zsh versão 5.0.2, arquivo de configuração on-my-zsh


Os caracteres são repetidos no comando que o zsh executa ou são meramente exibidos? O número de caracteres muda se o comando tiver mais de dois caracteres? O número muda quando o diretório atual é alterado?
Gilles 'SO- stop be evil'

@ Gilles O caractere repetido não existe no comando. Eu posso executar o comando.
jilen

Respostas:


32

Se os caracteres na linha de comando às vezes são exibidos em um deslocamento, isso geralmente ocorre porque o zsh calculou a largura incorreta para o prompt. Os sintomas são que a exibição parece boa, desde que você adicione caracteres ou mova caracteres por caractere, mas fique distorcida (com alguns caracteres aparecendo mais à direita do que deveria) quando você usa outros comandos que movem o cursor ( Homeconclusão, etc.) ) ou quando o comando se sobrepõe a uma segunda linha.

O Zsh precisa saber a largura do prompt para saber onde os caracteres do comando são colocados. Ele assume que cada personagem ocupa uma posição, a menos que seja dito o contrário.

Uma possibilidade é que seu prompt contenha seqüências de escape que não sejam adequadamente delimitadas. Seqüências de escape que alteram a cor ou outros aspectos de formatação do texto, ou que alteram o título da janela ou outros efeitos, têm largura zero. Eles precisam ser incluídos em uma construção de chaves de porcentagem%{…%} . De maneira mais geral, uma sequência de escape %42{…%}diz ao zsh para assumir que o que está dentro do aparelho tem 42 caracteres de largura.

Portanto, verifique suas configurações rápidas ( PS1, PROMPTou as variáveis que eles fazem referência) e certifique-se de que todas as sequências de escape (como \e[…mpara alterar atributos de texto - nota que pode estar presente através de algumas variáveis como $fg[red]) estão no interior %{…%}. Como você está usando o oh-my-zsh, verifique suas próprias configurações e as definições que você está usando no oh-my-zsh.

O mesmo problema surge no bash. É necessário incluir seqüências de largura zero em um prompt\[…\] .

Outra possibilidade é que o seu prompt contenha caracteres não ASCII e que o zsh (ou qualquer outro aplicativo) e o seu terminal tenham uma idéia diferente da largura deles. Isso pode acontecer se houver uma incompatibilidade entre a codificação do seu terminal e a codificada declarada no shell, e as duas codificações resultam em larguras diferentes para determinadas seqüências de bytes. Normalmente, você pode encontrar esse problema ao usar um terminal não-Unicode, mas declarando um código de idioma Unicode ou vice-versa.

Os aplicativos contam com variáveis ​​de ambiente para conhecer o código do idioma; a configuração relevante é LC_CTYPE, que é determinada a partir das variáveis de ambiente LANGUAGE, LC_ALL, LC_CTYPEe LANG(a primeira delas que está definido é aplicável). O comando locale | grep LC_CTYPEinforma sua configuração atual. Geralmente, a melhor maneira de evitar problemas de localidade é deixar o emulador de terminal definido LC_CTYPE, pois ele sabe qual codificação espera; mas se isso não funcionar para você, defina LC_CTYPE.

Os mesmos sintomas podem ocorrer quando o comando anterior exibiu alguma saída que não terminou em uma nova linha, para que o prompt seja exibido no meio da linha, mas o shell não percebe isso. Nesse caso, isso só aconteceria após a execução de um comando desse tipo, não persistentemente.

Se uma linha não for exibida corretamente, o comando redisplayou clear-screen(vinculado a Ctrl+ Lpor padrão) a corrigirá.


Acho que provavelmente estou faltando fonte relacionada, noto que o primeiro caractere é estranho. Espera-se ->que seja, eu acho
jilen 17/09/2013

@ jilen Ah, isso poderia ser outro problema que eu esqueci de mencionar: talvez seu prompt contenha caracteres não ASCII em uma codificação diferente do seu terminal, com uma ou ambas as codificações sendo multibyte. Se você quiser ajuda com isso, publique a saída de localee de echo $PS1 | od -t x1(e a mesma coisa com qualquer outra variável usada por $PS1).
Gilles 'SO- stop being evil'

2
Esqueci de definir o código do idioma (estou usando o archlinux, o código do idioma não é definido por padrão). Após definir a localidade, esse problema foi corrigido. Muito obrigado, cara !!!!
jilen

Eu votei nele porque, bem, é incrível. Mas as fugas não precisam ser absolutamente incluídas nos colchetes se você manipular a contagem de cursor por conta própria. chamar uma função subshelled funcionou para mim no passado - ou redirecionamentos que ainda permanecem em / dev / tty sem envolver stdout podem funcionar. Outros métodos que funcionaram - usando \e{7,8}para salvar / restaurar estados do cursor.
mikeserv

Foi o LC_CTYPEque consertou para mim. Eu tinha configurado para C, quando desmarcá-lo, tudo funcionava. Obrigado.
jmaloney


1

Eu tive esse problema no iTerm 2 no macOS. Acabei resolvendo o problema acessando Preferências -> Perfis -> Texto e assinalando "Usar larguras Unicode versão 9".


Uau, isso realmente funcionou. Obrigado!
Paul Calabro

1

Eu tenho esse problema usando o ubuntu lts docker image ( ubuntu:latest). Corrigi-o com as instruções fornecidas na página correspondente: https://hub.docker.com/_/ubuntu

apt-get update && \
apt-get install -y locales && \
rm -rf /var/lib/apt/lists/* && \
localedef -i en_US -c -f UTF-8 -A /usr/share/locale/locale.alias en_US.UTF-8
echo 'export LANG=en_US.utf8' >> ~/.zshrc
zsh
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.