Primeros caracteres del comando repetidos en la pantalla al completar

21

Los dos primeros caracteres se repitieron mientras yo Tabsolía completar. En la captura de pantalla a continuación, cdse repite.

ingrese la descripción de la imagen aquí

He intentado rxvt-unicdoe, xterm, terminator. Todos estos emuladores de terminal tienen este problema.

Zsh versión 5.0.2, archivo de configuración en-my-zsh

zsh line-editor oh-my-zsh jilen
fuente
¿Se repiten los caracteres en el comando que ejecuta zsh, o simplemente se muestran? ¿Cambia el número de caracteres si el comando tiene más de dos caracteres? ¿Cambia el número cuando cambia el directorio actual?
Gilles 'SO- deja de ser malvado'
@Gilles El carácter repetido no existe en el comando. Puedo ejecutar el comando.
jilen

Respuestas:

32

Si los caracteres en su línea de comando a veces se muestran en un desplazamiento, a menudo esto se debe a que zsh ha calculado el ancho incorrecto para la solicitud. Los síntomas son que la pantalla se ve bien siempre que esté agregando caracteres o moviendo carácter por carácter, pero se vuelve confusa (con algunos caracteres que aparecen más a la derecha de lo que deberían) cuando usa otros comandos que mueven el cursor ( Home, finalización, etc. ) o cuando el comando se superpone a una segunda línea.

Zsh necesita conocer el ancho de la solicitud para saber dónde se ubican los caracteres del comando. Se supone que cada personaje ocupa una posición a menos que se le indique lo contrario.

Una posibilidad es que su solicitud contenga secuencias de escape que no estén delimitadas correctamente. Las secuencias de escape que cambian el color u otros aspectos de formato del texto, o que cambian el título de la ventana u otros efectos, tienen un ancho cero. Deben incluirse dentro de una construcción de llaves porcentuales%{…%} . En términos más generales, una secuencia de escape como %42{…%}le dice a zsh que asuma que lo que está dentro de las llaves tiene 42 caracteres de ancho.

Por lo tanto, verifique la configuración de su solicitud ( PS1, PROMPTo las variables a las que hacen referencia) y asegúrese de que todas las secuencias de escape (como \e[…mcambiar los atributos de texto, tenga en cuenta que puede estar presente a través de alguna variable como $fg[red]) están dentro %{…%}. Como está usando oh-my-zsh, verifique tanto su propia configuración como las definiciones que está usando de oh-my-zsh.

El mismo problema surge en bash. Allí, las secuencias de ancho cero en una solicitud deben incluirse \[…\].

Otra posibilidad es que su solicitud contenga caracteres no ASCII y que zsh (o cualquier otra aplicación) y su terminal tengan una idea diferente de cuán anchos son. Esto puede suceder si hay una falta de coincidencia entre la codificación de su terminal y la codificación que se declara en el shell, y las dos codificaciones resultan en anchos diferentes para ciertas secuencias de bytes. Por lo general, puede encontrarse con este problema cuando utiliza un terminal que no es Unicode pero declara una configuración regional Unicode o viceversa.

Las aplicaciones se basan en variables de entorno para conocer la configuración regional; el ajuste relevante es LC_CTYPE, que se determina a partir de las variables de entorno LANGUAGE, LC_ALL, LC_CTYPEy LANG(el primero de estos que es conjunto se aplica). El comando locale | grep LC_CTYPEte dice tu configuración actual. Por lo general, la mejor manera de evitar problemas locales es dejar que se establezca el emulador de terminal LC_CTYPE, ya que sabe qué codificación espera; pero si eso no funciona para usted, asegúrese de configurarlo LC_CTYPE.

Los mismos síntomas pueden ocurrir cuando el comando anterior mostraba algún resultado que no terminaba en una nueva línea, de modo que el indicador se muestra en el medio de la línea pero el shell no se da cuenta de eso. En este caso, eso solo sucedería después de ejecutar dicho comando, no de forma persistente.

Si una línea no se muestra correctamente, el comando redisplayo clear-screen(vinculado a Ctrl+ Lde forma predeterminada) lo reparará.

Gilles 'SO- deja de ser malvado'
fuente
Supongo que probablemente me falte la fuente relacionada, noto que el primer carácter es extraño. Se espera que sea ->, creo
jilen
@jilen Ah, este podría ser otro problema que olvidé mencionar: tal vez su solicitud contiene caracteres no ASCII en una codificación diferente de su terminal, con una o ambas codificaciones siendo multibyte. Si desea ayuda con eso, publique la salida de localey de echo $PS1 | od -t x1(y lo mismo con cualquier otra variable utilizada por $PS1).
Gilles 'SO- deja de ser malvado'
2
Olvidé establecer la configuración regional (estoy usando archlinux, la configuración regional no se establece de forma predeterminada). Después de establecer la configuración regional, este problema está solucionado. Muchas gracias, chico !!!!
jilen
Lo voté porque, bueno, es bastante impresionante. Pero los escapes no tienen que estar absolutamente incluidos en los corchetes si de lo contrario maneja el recuento del cursor por su cuenta. Llamar a una función de subinstrucción me ha funcionado en el pasado, o las redirecciones que aún funcionan en / dev / tty sin involucrar stdout podrían funcionar. Otros métodos que han funcionado: usar \e{7,8}para guardar / restaurar estados del cursor.
mikeserv
Fue lo LC_CTYPEque me arregló. Lo tenía configurado C, cuando lo desarmado, todo funcionaba. Gracias.
jmaloney
1

Tuve este problema en iTerm 2 en macOS. Terminé resolviéndolo yendo a Preferencias -> Perfiles -> Texto y marcando "Usar anchos de Unicode versión 9".

Silwing
fuente
Wow, esto realmente funcionó. ¡Gracias!
Paul Calabro
1

Tengo este problema usando ubuntu lts docker image ( ubuntu:latest). Lo arreglé con las instrucciones proporcionadas en la página correspondiente: 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
Gleb Samsonenko
fuente