Ao imprimir arquivos com finais de linha do Windows (CRLF), less
mostra o retorno de carro ^M
em linhas em branco quando a opção --hilite-unread
é usada. Linhas com qualquer texto são exibidas corretamente, ignorando os retornos de carro.
Eu li o manual e parece que deve ser o mesmo, desde que CR seja seguido por LF. Adicionar --raw-control-chars
remove os marcadores, mas seu uso não é recomendado e tem outras consequências que não desejo.
$ printf 'first\r\n\r\nsecond\r\n' | LESS= less --quit-if-one-screen
first
second
$ printf 'first\r\n\r\nsecond\r\n' | LESS= less --quit-if-one-screen --hilite-unread
first
^M
second
$ printf 'first\r\n\r\nsecond\r\n' | LESS= less --quit-if-one-screen --hilite-unread --raw-control-chars
first
second
Isso é um bug conhecido less
ou há algo que eu possa fazer? Por enquanto vou apenas renunciar ao uso do --hilite-unread
.
Curiosamente, quando o texto é longo o suficiente para rolar, ao rolar para cima os ^M
marcadores desaparecem. Portanto, eles são exibidos apenas para as linhas recém-impressas. Possivelmente less
ainda não sabe que LF estará lá? Mas então por que isso funciona para linhas com texto?
Eu uso Git para Windows, versões: git 2.43.0.windows.1, bash 5.2.21(1), menos 643.
Algum tempo depois de postar a pergunta, percebi que devia ser um bug e criei um relatório de bug no repositório less, que foi prontamente confirmado e corrigido pelo desenvolvedor.
Para referência futura, o problema foi introduzido em
less
571 (30 de dezembro de 2020) e a correção provavelmente será incluída na próxima versão, ou seja.less
650 (ainda não lançado em 4 de fevereiro de 2024).O
--hilite-unread
(ou--HILITE-UNREAD
) insere um espaço nas linhas em branco para que haja sempre um caractere para destacar. Se a linha terminar com CR/LF, agora colocará o espaço antes do CR, não entre o CR e o LF. Assim, o CR será reconhecido corretamente como parte do final da linha e não será exibido como^M
.