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

Compatibilidade retroativa.

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

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 para a margem esquerda.

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

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

Para quem não conhece as máquinas de escrever, aqui está um vídeo mostrando como a digitação foi feita: link . Observe que o papel é movido pela primeira vez e, em seguida, o carro é retornado, mesmo que isso ocorra em um movimento simples. O ding notificou o datilógrafo de que o fim estava próximo e de se preparar para isso.

Até onde sei, isso remonta aos tempos das máquinas de escrever.

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

\n é uma nova linha, que move o seu papel para cima de uma linha.

Fazer apenas um deles 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, algumas pessoas mantiveram o modelo antigo, mas outros perceberam que não era necessário e encapsulavam uma nova linha completa como um caractere.

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

Retorno de carro significava "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 as linhas seriais.

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

Eu suspeito que, se você for longe o bastante, você encontrará um desacordo político entre os implementadores!

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

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

$ 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

História do personagem Newline (Wikipedia):

ASCII was developed simultaneously by the ISO and the ASA, the predecessor organization to ANSI. During the period of 1963–1968, the ISO draft standards supported the use of either CR+LF or LF alone as a newline, while the ASA drafts supported only CR+LF.

The sequence CR+LF was in common use on many early computer systems that had adopted teletype machines, typically an ASR33, as a console device, because this sequence was required to position those printers at the start of a new line. On these systems, text was often routinely composed to be compatible with these printers, since the concept of device drivers hiding such hardware details from the application was not yet well developed; applications had to talk directly to the teletype machine and follow its conventions.

The separation of the two functions concealed the fact that the print head could not return from the far right to the beginning of the next line in one-character time. That is why the sequence was always sent with the CR first. In fact, it was often necessary to send extra characters (extraneous CRs or NULs, which are ignored) to give the print head time to move to the left margin.

Even after teletypes were replaced by computer terminals with higher baud rates, many operating systems still supported automatic sending of these fill characters, for compatibility with cheaper terminals that required multiple character times to scroll the display.

MS-DOS (1981) adopted CP/M's CR+LF; CP/M's use of CR+LF made sense for using computer terminals via serial lines. This convention was inherited by Microsoft's later Windows operating system.

The Multics operating system began development in 1964 and used LF alone as its newline. Unix followed the Multics practice, and later systems followed Unix.

O que acontece com as pessoas perguntando "por que o Unix pode fazer \n e 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 arquivos lidam com as coisas. Além de onde o sistema operacional lê / grava configurações baseadas em texto ou comandos de linha de comando, não faz sentido culpar o sistema operacional.
2. A maioria dos aplicativos do Windows pode ler tanto \n quanto \r\n . Eles também produzem \r\n para que todos fiquem felizes. Um programa não "faz" apenas \n ou \r\n - aceita um, o outro, ou ambos, e gera um, o outro, ou ambos.
3. Como programador, isso deve quase nunca nunca incomodar você. Praticamente todas as linguagens / plataformas têm recursos para escrever a linha final correta e ler de maneira mais robusta. A única vez que tive que lidar com o problema foi quando eu escrevi um servidor HTTP - e foi porque um determinado navegador (dica: o próximo navegador mais popular após o IE) estava fazendo \n em vez de o correto \r\n .
4. Uma pergunta muito mais pertinente é: por que tantos aplicativos Unix modernos geram apenas \n sabendo que há alguns protocolos e programas que não gostam dela?

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

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 ao carro quando ele fez um avanço de linha.

O Windows veio do DOS, então, para o Windows, a pergunta é: por que o DOS usou essa sequência cr / lf? Eu estou supondo que tem algo a ver com CP / M, onde o DOS tem algumas de suas raízes. Mais uma vez, 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?

This protocol dates back to the days of teletypewriters. CR stands for "carriage return" - the CR control character returned the print head ("carriage") to column 0 without advancing the paper. LF stands for "linefeed" - the LF control character advanced the paper one line without moving the print head. So if you wanted to return the print head to column zero (ready to print the next line) and advance the paper (so it prints on fresh paper), you need both CR and LF.

If you go to the various internet protocol documents, such as RFC 0821 (SMTP), RFC 1939 (POP), RFC 2060 (IMAP), or RFC 2616 (HTTP), you'll see that they all specify CR+LF as the line termination sequence. So the the real question is not "Why do CP/M, MS-DOS, and Win32 use CR+LF as the line terminator?" but rather "Why did other people choose to differ from these standards documents and use some other line terminator?"

Unix adopted plain LF as the line termination sequence. If you look at the stty options, you'll see that the onlcr option specifies whether a LF should be changed into CR+LF. If you get this setting wrong, you get stairstep text, where

each
    line
        begins

where the previous line left off. So even unix, when left in raw mode, requires CR+LF to terminate lines. The implicit CR before LF is a unix invention, probably as an economy, since it saves one byte per line.

The unix ancestry of the C language carried this convention into the C language standard, which requires only "\n" (which encodes LF) to terminate lines, putting the burden on the runtime libraries to convert raw file data into logical lines.

The C language also introduced the term "newline" to express the concept of "generic line terminator". I'm told that the ASCII committee changed the name of character 0x0A to "newline" around 1996, so the confusion level has been raised even higher.