maneiras de corrigir automaticamente finais de linha em scripts de shell ou arquivos que quebram com ^ M

1

Problema

Nós regularmente quebramos as terminações das nossas linhas de arquivos e as coisas param de funcionar sem que percebamos.

O Bash reclama sobre "opção inválida" ou ": comando não encontrado" como descrito aqui: link

Estou preocupado que isso também possa quebrar outros arquivos de texto (conf, crons ...)

Como a quebramos (suponho)

Somos um grupo de pessoas que usam o Windows, Mac ou Linux para editar arquivos do Linux em um servidor. Nós editamos esses arquivos manualmente (ssh + vi / nano ou localy + ftp). Às vezes copiamos / colamos e acho que é isso que está causando o problema. Sim, às vezes não testamos nossas alterações por razões não tão boas: o mesmo script funciona no servidor replicado, a alteração é apenas o recuo de algumas linhas etc. Concordo que isso deve ser tratado.

Usar soluções semelhantes ao Chef / Puppet não é planejado.

Atualizar

Copiar e colar o TLDR não é um problema, o FTP é.

Eu fiz alguns testes com copiar / colar as terminações de linha do Windows CRLF no Windows + Notepad ++ + PuTTY + nano e vi. Parece que o caractere CR (^ M) é filtrado, apenas o LF é colado nos arquivos. Obrigado ewwhite por me fazer duvidar da teoria de copiar / colar!

Eu transferi um arquivo finalizado por CRLF via FTP usando o FileZilla, opção "Send mode" para automático. O CRLF é preservado. Gostaria de saber se o FileZilla poderia convertê-los em LFs.

Mitigação

Não podemos proibir sistemas operacionais não-Linux nem proibir copiar-colar.

Pensei nessas soluções:

  1. Construa um cron.minutely que execute dos2unix ou sed em todos os scripts. Contras: precisamos manter uma lista de "arquivos de texto modificáveis", pois não quero que seja executado em /
  2. Use um editor de texto que suporte comandos adicionais após a alteração do arquivo. Contras: poderia quebrar arquivos que legitimamente usam finais de linha não-Linux, não funciona quando nós scripts ftp.
  3. Use um sistema acionador como o link . Contras:?

Prós de 2 e 3: também podemos usá-los para adicionar uma linha em branco final aos programas que precisam dela.

Usando o bash, versão 4.2.37 (1) -release

Questões relacionadas com ^ M (CRLF)

Edit: Eu tenho um voto negativo, você poderia por favor explicar por quê?

    
por pyb 12.06.2014 / 19:23

1 resposta

4

Eu tenho que lidar com isso ocasionalmente com alguns sistemas legados. Às vezes, os arquivos mantidos no controle de origem da organização ( Borland Starteam ) estavam configurados para a configuração errada de alimentação de linha.

Mas, trabalhando em vários ambientes de plataforma cruzada, copiar / colar não deve causar esse problema sozinho. Tente identificar as tendências com base na saída das seguintes e lidar adequadamente com os piores transgressores.

Pesquise periodicamente arquivos com alimentações de linha do DOS.

find /var/www -not -type d -exec file "{}" ";" | grep CRLF

Exemplo:

# find /ppro/bin -not -type d -exec file "{}" ";" | grep CRLF
/ppro/bin/compile/save/srcfix.c: ASCII C program text, with CRLF line terminators
/ppro/bin/compile/bldtag.c: ASCII Pascal program text, with CRLF line terminators
/ppro/bin/compile/bldtag.c.sav: ASCII Pascal program text, with CRLF line terminators
/ppro/bin/compile/dbcsum2.c: ASCII Pascal program text, with CRLF line terminators
/ppro/bin/hphw/print_sv.c: ASCII text, with CRLF line terminators
/ppro/bin/linuxhw/dhcpd.conf: ASCII text, with CRLF line terminators
/ppro/bin/linuxhw/dhcpd.conf.mult_subnet: ASCII text, with CRLF line terminators

Então BURN eles !!

Lembre-se de que dos2unix em alguns sistemas modificará as permissões ...

    
por 12.06.2014 / 19:43