Perché questo prompt di bash a volte mantiene parte dei comandi precedenti durante lo scorrimento della cronologia?

Il mio prompt di bash, che ammetto di aver rubato da alcuni punti e messo insieme, a volte aggiungerà parte dei comandi precedenti alla sua lunghezza quando si scorre la cronologia di bash con le frecce su / giù.

Ad esempio, se i miei comandi precedenti fossero:

ls
cd /home/caleb
vim .bashrc

Quando ero al mio prompt e ho fatto scorrere due volte verso l'alto, potrebbe apparire come:

$ vim .bcd / home / caleb

Dove sono rimasti i primi cinque caratteri dall'ultimo comando.

Qualcuno ha idea del perché questo accada e come può essere fermato?

Il mio prompt è impostato con questo codice (troppo lungo per includerlo qui): https://gist.github.com/1679352

Da qualche parte il tuo prompt è fubar. Quello che succede di solito è che la tua shell pensa che stia generando codici di termini non stampabili e si aspetta che occupi spazio. Il miglior consiglio che posso darti è quello di aggiungere sistematicamente (o rimuovere) il tuo prompt fino a quando questo comportamento non si interrompe per isolare il codice che causa questo problema.

I codici colore devono essere racchiusi tra parentesi quadre. Le parentesi indicano a bash che il testo allegato non deve essere stampato

basandosi sull'esempio di @ Phreditor, questo mostra che qualsiasi formattazione eseguita dopo la nuova riga comporterà il problema originale:

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

il wrapping del codice di formato in [] garantisce che non si verifichino comportamenti fastidiosi:

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

La documentazione: http://tldp.org/HOWTO/Bash-Prompt-HOWTO/nonprintingchars.html

Poiché la formattazione di PS1 fa sì che il valore sia così lungo e difficile da leggere, inserisco i codici di formato in variabili:

BYELLOW='\[\033[01;33m\]'
IBLACK='\[\033[0;90m\]'
PS_CLEAR='\[\033[0m\]'
export PS1="\n${BYELLOW}[\w]${PS_CLEAR}\n${IBLACK}\$ "

Ho avuto lo stesso problema ed era correlato alle definizioni dei colori.

Nel mio caso, ho un prompt a più righe (dà più spazio al comando corrente indipendentemente dalla lunghezza del percorso visualizzata dal prompt).

Versione non valida:

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

Buona versione:

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

\033[00mtermina il colore. Se è dopo la nuova riga ( \n), impedisce un corretto ridisegno nel terminale, per sovrascrivere i comandi precedenti con il colore di sfondo. Spostandolo dietro la nuova linea si è risolto il problema.

(utilizzando Terminale in Mac OS 10.8)

In realtà penso che ciò abbia a che fare con un delimitatore mancante di "carattere non stampabile". Ho avuto esattamente lo stesso problema, ma spostandolo prima della nuova riga (\ n) non è stato risolto. Invece ho circondato correttamente tutti i caratteri non stampabili (qui, i comandi di colorazione) con '\ [' e '\]'.

Cattivo (funziona, ma presenta il problema di cancellazione della cronologia descritto sopra):

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

Buono (circondato da tutti i comandi di colore con '\ [' e '\]' - non mostra la cronologia dei comandi schiacciati):

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

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

E se lo stai inserendo in qualcosa come SecureCRT per l'invio automatico all'accesso a un sistema, potresti dover evitare il doppio di tutto (mettere doppie barre rovesciate ovunque) se il sistema di accesso automatico consuma la prima barra rovesciata stessa per determinare il carattere da inviare :

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

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

(Questo è sicuramente vero per SecureCRT e può essere vero per gli altri, come PuTTY o TeraTerm - test richiesti da parte tua.)