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

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

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.

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}\$ "

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)

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).