O prompt do Cygwin bash está quebrando linhas na mesma linha


56

Estou usando o prompt do Cygwin bash e, para comandos longos, o texto será contornado na mesma linha, em vez de ir para a próxima linha, apesar de definir meu PS1 simplesmente como '$'.

Aqui está uma captura de tela,
captura de tela


11
Qual é a TERMvariável de ambiente definida para? Para o console Cygwin, deveria ser cygwin.
ak2 14/05

1
@ ak2 isso resolveu o problema para mim, obrigado. Cygwin em Mintty.
JoshuaD

Respostas:


58

Eu já estava usando o MinTTY e remover a nova linha no PS1 também não ajudou. Um conselho nesta página ajudou. Eu executei este comando bash:

kill -WINCH $$

No meu caso, a execução desse problema corrigiu o problema, mesmo após o logoff e o logon novamente. Não tenho certeza se esse é sempre o caso.


1
A julgar por -WINCH, isso sinaliza ao processo do bash que a janela do terminal foi redimensionada. Portanto, isso deve ser feito após o redimensionamento de cada janela de terminal, eu acho.
ivan_pozdeev

7
@ivan_pozdeev, acabei de descobrir que você só precisa fazer isso: redimensionar enquanto o vim está aberto: o vim recebe o sinal e redesenha no novo tamanho, mas não é passado para o processo pai e, portanto, o bash ainda pensa no tamanho do A tela é o que era quando o vim foi aberto.
akatakritos

isso também funcionou para mim
Konqui

Isso funcionou para mim também, obrigado @jtpereyda!
Jason R. Mick

Obrigado, esse foi definitivamente o problema para mim - redimensionar o terminal enquanto estava no vim. Eu sinto que deve ser fácil o suficiente para corrigir esse bug, mas eu não sei.
Iguananaut 11/01

22

Para mim, a solução foi adicionar as seguintes linhas ao .bashrc:

PS1='\[\e[32m\]\u@\h:\W> \[\e[0m\]'
TERM=cygwin
export PS1
export TERM

Note que os caracteres não-imprimíveis no prompt de deve ser colocado em \[... \].


6
Conforme mencionado por @ ak2 em um comentário na pergunta original, a exportação TERM = cygwin é suficiente para corrigir o problema.
dregad 30/09/14

1
não foi suficiente no meu caso. se o PS1 contiver seqüências de escape que não estejam entre \ [... \], o problema de quebra de linha persistirá. definir a variável env TERM pode ser suficiente no seu caso, mas duvido.
Digory doo #

Para mim, isso corrige o problema de que a segunda linha sobrescreve a primeira, no entanto, a menos que eu use exatamente o terminal de 80 larguras, a posição do cursor e o deslocamento do texto ainda são instáveis ​​(usando cygwin64, mintty 2.3.7)
MM

Adicionando um problema [...] corrigido para mim.
Trismegistos

8

Eu também tive o mesmo problema com o MinTTY. O problema provavelmente tem algo a ver com o prompt primário (PS1).

A solução para mim foi remover o último caractere 'nova linha' do PS1 (logo antes do sinal '$'):

user@host ~
$ echo $PS1
\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$

user@host ~
$ export PS1='\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\$ '

user@host ~ $

consulte http://cygwin.com/ml/cygwin/2001-07/msg00140.html para obter referência.

Para tornar essa alteração persistente, adicione a exportação PS1 = '[\ e] 0; \ w \ a] \ n [\ e [32m] \ u @ \ h [\ e [33m] \ w [\ e [0m] \ $ 'para o seu arquivo ~ / .bashrc.


1
Não funcionou para mim ...
HDave 26/03

Isso funcionou para mim, mas, além de remover a última nova linha, também tive que reiniciar o terminal Cygwin.
christosc

5

Como comentado por dregad e ak2 , a configuração export TERM=cygwinno meu ~/.bashrcarquivo foi suficiente para corrigir esse problema para mim.


5

A resposta de @ jtpereyda está certamente certa. Mas, por alguma razão, não pude deixar isso de lado e me aprofundou um pouco mais.

Expandindo esse comentário , se você redimensionar o terminal enquanto estiver no vim (ou qualquer outro aplicativo de tela cheia que controle o tty do shell), o resultado SIGWINCHgeralmente não será enviado ao shell, portanto, quando ele voltar ao controle, não sabe que o terminal foi redimensionado.

Quando você redimensiona seu terminal, ele deve chamar um ioctl(..., TIOCSWINSZ, ...)pty no qual o vim está sendo executado. Isso resulta em um killpg(SIGWINCH)grupo de processos no vim.

O problema é que o vim é executado em seu próprio grupo de processos distinto do shell do qual foi executado, portanto, o shell bash não recebe SIGWINCHe não ajusta suas linhas / colunas adequadamente.

Se você deseja uma solução permanente, adicione shopt -s checkwinsizeao seu .bashrc. Isso faz com que o bash verifique o tamanho da janela ( ioctl(..., TIOCGWINSZ, ..)) após retornar de cada comando e atualize suas linhas / colunas.


O que o vim vai fazer com a pergunta? O OP não está usando o vim.
DavidPostill

1
Eu pretendia fazer referência a uma pergunta diferente que acho que tornou a conexão mais óbvia, mas, em suma, uma possível causa do problema do OP é abrir um aplicativo de terminal completo como o vim, redimensionar o terminal e sair. Como expliquei, o SIGWINCH não é visto pelo shell; portanto, quando você sai do vim, ainda acha que o terminal é do tamanho anterior, resultando em vários problemas de quebra de linha.
Iguananaut 11/01


2

Algo está quebrado nas configurações do seu terminal (provavelmente).
Eu acho que você já teria tentado sair dessa sessão e reiniciar uma nova.

Enquanto você não obtém uma solução para o terminal Cygwin, experimente o MinTTY (é realmente melhor).


1
Vejo esse problema no Cygwin em várias máquinas, mas o MinTTY parece melhor e resolve o problema de empacotamento. Dois pássaros com uma pedra!
wting 14/05

Observe que MinTTY é o terminal padrão para Cygwin desde o final de 2011 .
Hugh W

1

Como comentado por akatakritos , você provavelmente redimensionou seu terminal enquanto o vim estava aberto.

Quando isso acontece, basta redimensionar o terminal mais uma vez e o problema desaparece.


valeu! embora eu não esteja usando o cygwin, isso corrigiu o problema de "quebra automática da mesma linha" para mim no bash - apenas desmaximize a janela do terminal, depois maximize-a novamente e o problema desaparecerá :)
Nick Humphrey
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.