Espaço em branco da cor de fundo quando o final do terminal é atingido

Question

Estou trabalhando com sequências de controle para formatação de texto e tropeço em algum comportamento inesperado. Eu tenho algum texto para saída, no meio deste texto há algum bloco de texto menor realçado com um fundo colorido. O texto original pode ser bem longo, pode levar algumas linhas, então o bloco de texto colorido no meio pode aparecer nas várias linhas - inicia na linha e termina na outra linha. Tudo parece funcionar bem até atingir a parte inferior da janela do terminal, muito espaço em branco fica colorido:

Aquiestáumscriptparareproduzir:

#color.shecho-e'default\x1B[43mcolor\ncolor\x1B[49mdefault';

Comovocêpodever,euadicioneiumcaracteredenovalinha\nnoblocodetexto,apenasparareproduzir,masaminhasituação,quandoumtextoémuitolongoenãocabeemumaúnicalinha,blococoloridoédivididoemváriaslinhase,comoresultado,tenhoomesmoespaçoembrancoapósotexto.

#color-long.shecho-e'defaultdefaultdefaultdefaultdefaultdefaultdefaultdefaultdefault\x1B[43mcolorcolor\x1B[49mdefault';

Eu entendo isso no Ubuntu 14.04, mas consegui reproduzir o mesmo comportamento no Yosemite 10.10.

Gostaria de saber qual é o motivo desse comportamento e como ele pode ser corrigido sem usar diferentes utilitários para saída (em vez de echo ), mas talvez usando as mesmas seqüências de controle. Eu tenho controle sobre o texto, mas não sobre o processo de saída.

Já tentei encapsular sequências como \[\x1B[43m\] , []1\x1B[43m%code%2 , mas isso não dá resultado, apenas adiciona %code% extra ao texto ou gera alguns símbolos não reconhecidos.

    

Answer 1

Isto não tem nada a ver com bash, é puramente um efeito do comportamento do terminal, especificamente scroll. Quando você alcança a parte inferior da tela e começa a digitar na próxima linha, o terminal cria uma nova linha em branco empurrando tudo para cima em uma linha. (Nos terminais mais antigos, isso destrói a linha superior. Nos terminais mais recentes, a linha superior é apenas empurrada para o buffer de rolagem.) Agora, aqui está a pergunta difícil, que cor é a nova linha. A cor do primeiro plano não é um problema, porque você não pode vê-lo, mas a cor do plano de fundo. . . (Nos dias em que começavam a discutir, podiam ser cinza-preto ou branco (ou, na verdade, preto-verde, verde-claro ou o mesmo em âmbar). Havia experimentos para usar apenas preto, mas havia reclamações. O que foi resolvido é que a nova linha (ou a área desmarcada em uma tela inteira limpa no caso de uma tela clara) teria a cor de fundo atual como a cor de fundo da área afetada. Portanto, esse comportamento é por design, porque faz a coisa certa na maioria dos casos.

Então, o que você quer fazer para obter o comportamento desejado? Quando você mudar de volta para fundo preto (ou no final da linha), envie uma clara para o final da linha, a qual definirá a cor de fundo para o resto da linha.

    

Answer 2

Concordando com @hildred que este é um comportamento específico do terminal, há alguns pontos de discordância:

• se um aplicativo for alternado para a tela alternativa (como em um programa de tela inteira em execução no xterm, com uma descrição de terminal adequada), nenhum texto será deslocado para o buffer de rolagem.
• não há comportamento "certo" ou "errado", mas apenas convenções.
• existem vários recursos relacionados no design do terminal que (podem ser) independentes.
• devido à convenção (e alguns exemplos, como o console do Linux, xterm e - um pouco diferente - rxvt), muitos terminais de cores se comportam de maneira semelhante.
• O FAQ das ncurses Meu terminal mostra alguns espaços sem cor em mais detalhes.

A convenção é um argumento strong; Os programas dependem dessas opções de design que não mudam. Para alguns exemplos em que isso leva a problemas, considere alguns casos:

• linux 2.6.26 vt back_color_erase : Alterações no driver do console Linux quebraram o modelo como reportado em Novell # 418613 .
• Algumas atualizações no xterm levaram a sua cor do cursor a aparecer nas novas linhas de rolagem (mencionadas no xterm patch # 242 em relação ao Debian # 252873 , bem como ao Debian # 522141 )

Um recente relatório de bug para o VTE, # 754596 , fornece uma leitura divertida. Parece que os desenvolvedores da VTE sugeriram apenas mudar o comportamento para ver o que acontece:

For starter, we could just "fix" our code (remove the "Match xterm and fill the new row when scrolling" 6 lines from _vte_terminal_cursor_down()) for the next development cycle and see if anyone complains about something breaking. Then we'll have a better understanding of the situation.