Diferença entre '\ n' e '\ r \ n'

Sim, sim, estou ciente de que '\n'escreve uma nova linha em UNIX, enquanto para o Windows não é a seqüência de dois caracteres: '\r\n'. Tudo isso é muito bom em teoria, mas minha pergunta é por quê ? Por que o caractere de retorno de carro é extra no Windows? Se o UNIX pode fazer isso, \npor que o Windows leva dois caracteres para fazer isso?

Estou lendo o livro Python de David Beazley e ele diz:

Por exemplo, no Windows, escrever o caractere '\ n' na verdade gera a sequência de dois caracteres '\ r \ n' (e ao ler o arquivo novamente, '\ r \ n' é convertido novamente em um único '\ n' personagem).

Por que o esforço extra?

Eu serei honesto. Eu conheço a diferença há muito tempo, mas nunca me preocupei em perguntar por que. Espero que isso seja respondido hoje.

Obrigado pelo seu tempo.

Compatibilidade com versões anteriores.

O Windows é compatível com versões anteriores do MS-DOS (agressivamente, até mesmo) e o MS-DOS usou a convenção CR-LF porque o MS-DOS era compatível com o CP / M-80 (um tanto por acidente) que usou a convenção CR-LF porque Foi assim que você dirigiu uma impressora (porque as impressoras eram originalmente máquinas de escrever controladas por computador).

As impressoras têm um comando separado para mover o papel uma linha para uma nova linha e um comando separado para retornar o carro (onde o papel foi montado) de volta à margem esquerda.

É por isso. E, sim, é um aborrecimento, mas faz parte do acordo que permitiu ao MS-DOS conquistar o CP / M e o Windows 95 conquistar todas as outras GUIs do DOS e o Windows XP assumir o controle. do Windows 98.

(Nota: As impressoras a laser modernas ainda possuem esses comandos porque também são compatíveis com as impressoras anteriores - a HP, em particular, faz isso bem)

Para aqueles que não estão familiarizados com as máquinas de escrever, aqui está um vídeo mostrando como a digitação foi feita: http://www.youtube.com/watch?v=LJvGiU_UyEQ . Observe que o papel é movido primeiro para cima e, em seguida, o carro é devolvido, mesmo que isso aconteça em um movimento simples. O ding notificou o datilógrafo que o fim estava próximo e se preparava para isso.

Tanto quanto sei, isso remonta aos dias das máquinas de escrever.

\r é o retorno de carro, que é o que move o local onde você está digitando na página de volta para a esquerda (ou para a direita, se essa é sua cultura)

\n é uma nova linha, que move seu papel uma linha.

Fazer apenas um desses em uma máquina de escrever o colocaria no lugar errado para começar a escrever uma nova linha de texto.

Quando os computadores surgiram, acho que algumas pessoas mantiveram o modelo antigo, mas outras perceberam que não era necessário e encapsularam uma nova linha completa como um personagem.

Não sei se isso é de conhecimento comum, mas deve-se notar que o CR ainda é entendido pelos modernos emuladores de terminal:

$ printf "hey world\rsup\n"
sup world

É útil para indicadores de progresso, por exemplo

for i in {1..100}
do
    printf "\rLoading... %d%%" $i
    sleep 0.01
done
echo

Historicamente, o avanço de linha significava que o cilindro - o rolo no qual você digita - girava uma linha, fazendo com que o texto apareça na próxima linha ... mas na próxima coluna.

Retorno de carro significa "retornar o bit com o qual você digita no início da linha".

O Windows usa CR + LF porque o MS-DOS fez, porque o CP / M fez, porque fazia sentido para linhas seriais.

O Unix copiou sua \ n convenção porque Multics o fez.

Suspeito que, se você voltar o suficiente, encontrará um desacordo político entre os implementadores!

(Você deixou de lado a parte divertida, onde a convenção do Mac é (ou costumava ser) usar apenas o CR para separar linhas. E agora o Unicode também tem seu próprio separador de linhas, U + 2028!)

História do personagem da nova linha (Wikipedia):

O ASCII foi desenvolvido simultaneamente pela ISO e pela ASA, a organização predecessora da ANSI. Durante o período de 1963 a 1968, os rascunhos das normas ISO apoiaram o uso de CR + LF ou LF sozinhos como uma nova linha, enquanto os rascunhos da ASA suportaram apenas CR + LF.

A sequência CR + LF era de uso comum em muitos sistemas de computadores antigos que adotavam máquinas de teletipo, geralmente um ASR33, como um dispositivo de console, porque essa sequência era necessária para posicionar essas impressoras no início de uma nova linha. Nesses sistemas, o texto era frequentemente rotineiramente composto para ser compatível com essas impressoras, pois o conceito de drivers de dispositivo que escondia esses detalhes de hardware do aplicativo ainda não estava bem desenvolvido; os aplicativos precisavam conversar diretamente com a máquina de teletipo e seguir suas convenções.

A separação das duas funções ocultava o fato de que a cabeça de impressão não podia retornar da extrema direita para o início da próxima linha no tempo de um caractere. É por isso que a sequência sempre foi enviada com o CR primeiro. De fato, muitas vezes era necessário enviar caracteres extras (CRs ou NULs estranhos, que são ignorados) para dar tempo ao cabeçote de impressão para mover para a margem esquerda.

Mesmo depois que os teletipos foram substituídos por terminais de computador com taxas de transmissão mais altas, muitos sistemas operacionais ainda suportavam o envio automático desses caracteres de preenchimento, para compatibilidade com terminais mais baratos, que exigiam vários caracteres para rolar a tela.

MS-DOS (1981) adotou o CR / LF do CP / M; O uso de CR + LF pela CP / M fazia sentido para o uso de terminais de computador por meio de linhas seriais. Essa convenção foi herdada pelo sistema operacional Windows da Microsoft.

O sistema operacional Multics começou o desenvolvimento em 1964 e usou a LF sozinha como sua nova linha. O Unix seguiu a prática de Multics, e os sistemas posteriores seguiram o Unix.

O que há com as pessoas perguntando "por que o Unix pode fazer \ne não o Windows"? É uma pergunta tão estranha.

1. O sistema operacional não tem quase nada a ver com isso. É mais uma questão de como aplicativos, bibliotecas, protocolos e formatos de arquivo lidam com as coisas. Além de onde o sistema operacional lê / grava comandos baseados em texto ou de configuração de linha de comando, não faz sentido danificar o sistema operacional.
2. A maioria dos aplicativos do Windows pode ler ambos \ne \r\nmuito bem. Eles também produzem \r\npara que todos fiquem felizes. Um programa não simplesmente "faz" um \nou outro \r\n- ele aceita um, o outro ou ambos, e gera um, o outro ou ambos.
3. Como programador, isso quase nunca deve incomodá-lo. Praticamente todos os idiomas / plataformas possuem facilidades para escrever a linha final correta e ler com mais robustez. A única vez que tive que lidar com o problema foi quando escrevi um servidor HTTP - e foi porque um determinado navegador (dica: o próximo navegador mais popular depois do IE) estava funcionando, em \nvez do correto \r\n .
4. Uma pergunta muito mais pertinente é: por que tantos aplicativos Unix modernos saem apenas \nsabendo que existem alguns protocolos e programas que não gostam?

A razão pela qual as convenções mantêm seus vários sistemas (\ n em sistemas do tipo unix, \ r \ n no Windows, etc) é que, depois de escolher uma convenção, você NÃO pode alterá-la sem quebrar um monte de arquivos das pessoas. E isso geralmente é desaprovado.

Os sistemas do tipo Unix foram desenvolvidos (muito cedo) usando vários modelos de teletipo e, em algum momento, alguém decidiu que o equipamento deveria retornar o carro quando fazia um avanço de linha.

O Windows veio do DOS; portanto, para o Windows, a pergunta realmente é: Por que o DOS usou essa sequência cr / lf? Acho que tem algo a ver com o CP / M, onde o DOS tem algumas raízes. Novamente, modelos específicos de teletipo podem ter desempenhado um papel.

Aqui está uma resposta da melhor fonte - Microsoft. Por que o terminador de linha CR + LF?

Este protocolo remonta aos dias das máquinas de escrever. CR significa "retorno de carro" - o caractere de controle CR retornou a cabeça de impressão ("carro") para a coluna 0 sem avançar o papel. LF significa "avanço de linha" - o caractere de controle LF avançou o papel uma linha sem mover a cabeça de impressão. Portanto, se você deseja retornar a cabeça de impressão para a coluna zero (pronta para imprimir a próxima linha) e avançar o papel (para que seja impresso em papel novo), precisará de CR e LF.

Se você acessar os vários documentos de protocolo da Internet, como RFC 0821 (SMTP), RFC 1939 (POP), RFC 2060 (IMAP) ou RFC 2616 (HTTP), verá que todos eles especificam CR + LF como o sequência de terminação de linha. Portanto, a verdadeira questão não é "Por que CP / M, MS-DOS e Win32 usam CR + LF como terminador de linha?" mas "Por que outras pessoas optaram por diferir desses documentos de normas e usar algum outro terminador de linha?"

O Unix adotou LF simples como a sequência de terminação da linha. Se você observar as opções stty, verá que a opção onlcr especifica se um LF deve ser alterado para CR + LF. Se você errar essa configuração, receberá um texto na escada, onde

each
    line
        begins

onde a linha anterior parou. Portanto, mesmo o unix, quando deixado no modo bruto, requer que o CR + LF encerre as linhas. O CR implícito antes de LF é uma invenção unix, provavelmente como uma economia, pois economiza um byte por linha.

A ancestralidade unix da linguagem C carregava essa convenção no padrão da linguagem C, que requer apenas "\ n" (que codifica LF) para terminar as linhas, sobrecarregando as bibliotecas de tempo de execução para converter os dados brutos do arquivo em linhas lógicas.

A linguagem C também introduziu o termo "nova linha" para expressar o conceito de "terminador de linha genérico". Disseram-me que o comitê ASCII mudou o nome do personagem 0x0A para "nova linha" por volta de 1996, então o nível de confusão foi aumentado ainda mais.