O Que É CRLF vs LF? Diferenças de Quebra de Linha Explicadas

CRLF e LF são os dois estilos comuns de fim de linha: o Windows encerra linhas com carriage-return mais line-feed, enquanto o Unix usa apenas line-feed.

CRLF versus LF é a briga específica e prática por trás da maioria dos problemas de fim de linha. As ferramentas do Windows usam CRLF por padrão, enquanto Linux e macOS usam LF, e o CI normalmente roda em Linux. Quando arquivos cruzam essa fronteira sem normalização, scripts falham e diffs viram ruído. Esta é a versão do dia a dia da história de fim de linha, focada no que de fato fazer.

O que são CRLF e LF

LF é um único byte de line-feed. CRLF é um byte de carriage-return seguido de um byte de line-feed. Ambos encerram uma linha, mas o CRLF usa dois bytes onde o LF usa um. O carriage-return extra do CRLF é o causador de problemas quando um arquivo CRLF é processado por uma ferramenta que espera LF.

A divisão entre Windows e Unix

A divisão é histórica: o CRLF vem da era dos teletipos e persistiu no Windows, enquanto o Unix simplificou para LF. Hoje a maioria dos runners de CI, containers e servidores são Linux e esperam LF, então arquivos CRLF escritos no Windows são a fonte usual de atrito.

Como isso quebra o CI

Um shell script salvo com CRLF tem um carriage-return invisível no fim da linha do shebang, então o runner tenta executar um caminho de interpretador com um CR ao final e falha com um erro confuso de "no such file". Comparações de strings e parsing de configuração também divergem silenciosamente por causa do byte oculto.

Resolvendo com o gitattributes

A correção durável é deixar o git normalizar os finais de linha. Um arquivo .gitattributes declara que arquivos de texto são versionados como LF, então independentemente do editor ou do sistema operacional, o runner sempre vê LF. Isso é mais confiável do que pedir a cada colaborador que configure o editor.

# Force LF for scripts so CI never sees CRLF
* text=auto eol=lf
*.sh text eol=lf

Diagnóstico rápido

Se um script roda localmente no Windows mas morre imediatamente em um runner Linux, suspeite de CRLF. Ferramentas como file ou cat com caracteres de controle visíveis revelam os carriage returns. Converter para LF (com dos2unix ou normalização do git) normalmente resolve na hora.

Principais conclusões

• LF é um byte; CRLF é carriage-return mais line-feed - o Windows usa CRLF, o Unix usa LF.
• O CI roda em Linux, então scripts com CRLF falham com erros confusos de shebang e de arquivo não encontrado.
• Uma regra no .gitattributes forçando LF em arquivos de texto é a correção confiável para CI multiplataforma.

Guias relacionados