¿Por qué este mensaje bash a veces mantiene parte de los comandos anteriores al desplazarse por el historial?

29

Mi indicador de bash, que admitiré haber robado en algunos lugares y haber improvisado, algunas veces agregará parte de los comandos anteriores a su longitud al desplazar el historial de bash con flechas arriba / abajo.

Por ejemplo, si mis comandos anteriores fueron:

ls
cd /home/caleb
vim .bashrc

Cuando estaba en mi indicador y me desplacé dos veces hacia arriba, podría parecer:

$ vim .bcd / inicio / caleb

Donde quedan los primeros cinco caracteres del último comando.

¿Alguien tiene alguna idea de por qué sucede esto y cómo se puede detener?

Mi mensaje se configura con este código (es muy largo incluirlo aquí): https://gist.github.com/1679352

bash prompt Caleb Thompson
fuente
1
Establezca PS1 en un valor sin toda la basura vcs y vea qué sucede. Esa es mi suposición.
Daniel Beck
¿Ya has encontrado al culpable en tu aviso? Estoy teniendo el mismo problema
acme
Sí, bash lo pierde en los colores y no puede separar la longitud de las cadenas con escapes de color de la longitud de la cadena visible. Esto es a lo que SiegeX estaba llegando. Terminé cambiando a ZSH y usando un indicador diferente. ZSH no tiene el mismo problema.
Caleb Thompson
1
Ambas respuestas anteriores no resolvieron mi problema y no dieron ninguna explicación de por qué sucedió esto. Verifique que el mensaje Custom Bash se sobrescriba , si alguien ha buscado hasta este punto.
D3Hunter
Problema
matthiasbe

Respuestas:

6

En algún lugar tu aviso es fubar. Lo que generalmente sucede es que su shell cree que está generando códigos de términos no imprimibles y espera que ocupe espacio. El mejor consejo que puedo darle es agregar sistemáticamente (o quitar) su solicitud hasta que este comportamiento se detenga para aislar el código que está causando este problema.

SiegeX
fuente
37

Los códigos de color deben estar entre corchetes. Los corchetes informan a bash que el texto adjunto no debe imprimirse

basándose en el ejemplo de @ Phreditor, esto muestra que cualquier formateo realizado después de la nueva línea dará como resultado el problema original:

export PS1="\n\n\[\033[01;33m[\w]\033[00m\n\033[0;90m\$ "

envolver el código de formato en [] asegura que nunca se produzca un comportamiento molesto:

export PS1="\n\[\[\033[01;33m\][\w]\[\033[00m\]\n\[\033[0;90m\]\$ "

La documentación: http://tldp.org/HOWTO/Bash-Prompt-HOWTO/nonprintingchars.html

Dado que el formato PS1 hace que el valor sea tan largo y difícil de leer, pongo los códigos de formato en variables:

BYELLOW='\[\033[01;33m\]'
IBLACK='\[\033[0;90m\]'
PS_CLEAR='\[\033[0m\]'
export PS1="\n${BYELLOW}[\w]${PS_CLEAR}\n${IBLACK}\$ "
m79lkm
fuente
3
Esta debería ser la respuesta aceptada. Resolvió el problema.
Atcold
1
Cabe señalar (porque no pude notarlo;)), que en ese lío de barras invertidas y corchetes, los corchetes que siguen la secuencia de escape \033NO se deben escapar. Solo se deben escapar los corchetes envolventes.
Benjam
Es confuso para mí tratar con todos esos caracteres especiales, usar el primer resultado de Google me ayudó a generar un mensaje de trabajo exactamente como lo quería: ezprompt.net
Mallox
He estado queriendo personalizar mis colores de solicitud durante AÑOS, ¡pero nunca lo he hecho ya que siempre tuve este problema! Nunca pude entender por qué, así que simplemente me detuve y mantuve todo en blanco ... Estaba configurando una nueva computadora y finalmente me di cuenta de que realmente Google tenía el problema por una vez ... ¡Me alegro de haberlo hecho! Gracias por esta maravillosa lección.
TylerH4
8

Tuve el mismo problema y estaba relacionado con las definiciones de color.

En mi caso, tengo un mensaje de varias líneas (da más espacio para el comando actual, independientemente de la longitud de la ruta que se muestra por mensaje).

Mala versión:

export PS1="\n\n\[\033[01;33m[\w]\n\033[00m\$ "

Buena versión:

export PS1="\n\n\[\033[01;33m[\w]\033[00m\n\$ "

\033[00mtermina el color Si está después de la nueva línea ( \n), evita que se vuelva a dibujar correctamente en el terminal, para sobrescribir comandos anteriores con color de fondo. Moverlo detrás de la nueva línea resolvió el problema.

(usando Terminal en Mac OS 10.8)

Phreditor
fuente
Esto identificó el problema para mí, mientras que la respuesta aceptada actual era demasiado genérica.
Brian
Esta es la respuesta más precisa y debería ser la ganadora (y también fue la solución a mi problema).
craveytrain
el \neran el culpable para mí también. ¡Gracias!
mhulse
3

De hecho, creo que esto tiene que ver con un delimitador de "carácter no impreso" que falta. Tuve exactamente el mismo problema, pero moverlo antes de la nueva línea (\ n) no lo solucionó. En su lugar, rodeé correctamente todos los caracteres que no se imprimen (aquí, comandos para colorear) con '\ [' y '\]'.

Malo (funciona, pero tiene el problema de mezcla de historial descrito anteriormente):

PS1="\e[32m\u\e[35m@\e[32m\h \e[33m\w\e[36m\n\$\e[0m"

Bien (rodeado de todos los comandos de color con '\ [' y '\]', no muestra el historial de comandos combinados):

PS1="\[\e[32m\]\u\[\e[35m\]@\[\e[32m\]\h \[\e[33m\]\w\[\e[36m\]\n\$\[\e[0m\]"

i.e. "\e[...m" --becomes--> "\[\e[...m\]"

Y si está colocando esto en algo como SecureCRT para enviarlo automáticamente al iniciar sesión en un sistema, es posible que tenga que escapar dos veces (poner barras diagonales dobles en todas partes) si el sistema de inicio de sesión automático consume la primera barra invertida para determinar el carácter que se enviará :

PS1="\\[\\e[32m\\]\\u\\[\\e[35m\\]@\\[\\e[32m\\]\\h \\[\\e[33m\\]\\w\\[\\e[36m\\]\\n\\$\\[\\e[0m\\]"

i.e. "\..." --becomes--> "\\..."

(Esto es definitivamente cierto para SecureCRT y puede ser cierto para otros, como PuTTY o TeraTerm; se requieren pruebas de su parte).

skeetastax
fuente