Eu estava ficando um pouco cansado dos meus erros no Bash de bagunçar o PS1. Por exemplo, eu executaria um comando, como ls , e enquanto ele estiver em execução, comece a digitar o próximo comando, como echo , e o typeahead de echo apareceria antes do PS1, como
/$ls
...
ec/$echo
(aqui /$ é o PS1 ). Minha solução para isso foi adicionar \r à frente do PS1, para que ele fosse limpar a linha primeiro.
Isso parece funcionar razoavelmente bem, mas parece haver um problema estranho. No meu .inputrc , eu tenho
"\ep": history-search-backward
para me deixar digitar M-p para retroceder (iTerm 2 maps Opção para escapar corretamente)
O problema é que às vezes quando eu digito algumas coisas e depois M-p para obter o comando anterior, eu faço um C-u C-k para limpar a linha, o primeiro caractere fica e se torna parte do PS1 ( é deletado da linha executada, mas é mostrado no PS1). Não acontece quando eu executo o comando, mas sempre que eu bato esse item no histórico, mesmo com a seta para cima regular, esse primeiro caractere fica preso lá novamente. Isso só parece acontecer com comandos que são de um certo tamanho. Não importa se o \r realmente limpa qualquer texto para que isso aconteça.
Estou acertando um bug estranho no bash e / ou no iTerm? Está adicionando \r à frente de PS1 da maneira correta de limpar o lixo antes?
Sinaliza para bash que o \r é um caractere não imprimível para que o comprimento correto da string de prompt seja calculado, ou seja, em vez de
PS1='\rstuff'
use
PS1='\[\r\]stuff'
Acho que, como \r está no início do prompt, ele é sempre um caractere de comprimento zero, em vez de um caractere de largura negativa de comprimento variável, pois pode ser considerado se ocorrer no meio do prompt som onde, então isso deve funcionar.
Tags bash ps1 iterm2 carriage-return