Meu prompt bash, que eu admito ter roubado de alguns lugares e remendado, algumas vezes adicionará parte dos comandos anteriores ao seu comprimento ao rolar o histórico bash com setas para cima / para baixo.
Por exemplo, se meus comandos anteriores forem:
ls
cd /home/caleb
vim .bashrc
Quando eu estava no meu prompt e rolava para cima duas vezes, pode parecer:
$ vim .bcd /home/caleb
Onde os primeiros cinco caracteres são deixados do último comando.
Alguém sabe por que isso está acontecendo e como isso pode ser interrompido?
O meu pedido está definido com este código (forma de incluir aqui): link
Em algum lugar, seu aviso é fubar. O que geralmente acontece é que o seu shell acha que ele imprime códigos de termo não imprimíveis e espera que ele ocupe espaço. O melhor conselho que posso dar é adicionar sistematicamente (ou tirar) seu prompt até que esse comportamento pare para isolar o código que está causando esse problema.
Os códigos de cores precisam ser agrupados em colchetes. Os parênteses informam bash que o texto anexo não deve ser impresso
Com base no exemplo @ do Phreditor, isso mostra que qualquer formatação feita após a nova linha resultará no problema original:
export PS1="\n\n\[3[01;33m[\w]3[00m\n3[0;90m\$ "
agrupar o código de formato em [] garante que o comportamento irritante nunca aconteça:
export PS1="\n\[\[3[01;33m\][\w]\[3[00m\]\n\[3[0;90m\]\$ "
A documentação: link
Como a formatação do PS1 faz com que o valor seja tão longo e difícil de ler, eu coloco os códigos de formato em variáveis:
BYELLOW='\[3[01;33m\]'
IBLACK='\[3[0;90m\]'
PS_CLEAR='\[3[0m\]'
export PS1="\n${BYELLOW}[\w]${PS_CLEAR}\n${IBLACK}\$ "
Eu tive o mesmo problema e estava relacionado às definições de cor.
No meu caso, eu tenho um prompt de várias linhas (dá mais espaço para o comando atual, independentemente do tamanho do caminho exibido pelo prompt).
Versão incorreta:
export PS1="\n\n\[3[01;33m[\w]\n3[00m\$ "
Boa versão:
export PS1="\n\n\[3[01;33m[\w]3[00m\n\$ "
3[00m termina a cor. Se for depois da nova linha ( \n ), previne o redesenho adequado no terminal, para sobrescrever comandos anteriores com cor de fundo. Movê-lo para trás da nova linha resolveu o problema.
(usando o Terminal no Mac OS 10.8)
Na verdade, acho que isso tem a ver com um delimitador 'caractere não-imprimível' ausente. Eu tive exatamente o mesmo problema, mas movê-lo antes da nova linha (\ n) não o corrigiu. Em vez disso, rodei corretamente todos os caracteres não imprimíveis (aqui, comandos de coloração) com '\ [' e '\]'.
Ruim (funciona, mas tem o problema de esmagamento de histórico descrito acima):
PS1="\e[32m\u\e[35m@\e[32m\h \e[33m\w\e[36m\n\$\e[0m"
Bom (rodando todos os comandos de cor com '\ [' e '\]' - não mostra o histórico do comando mashed):
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 você está colocando isso em algo como SecureCRT para enviar automaticamente após o login em um sistema, você pode ter que escapar tudo (colocar barras duplas em todos os lugares) se o sistema de login automático consome a primeira barra invertida para determinar o caractere para ser enviado:
PS1="\[\e[32m\]\u\[\e[35m\]@\[\e[32m\]\h \[\e[33m\]\w\[\e[36m\]\n\$\[\e[0m\]"
i.e. "\..." --becomes--> "\..."
(Isto é definitivamente verdade para o SecureCRT e pode ser verdade para outros, como PuTTY ou TeraTerm - teste requerido de sua parte).