Differenza tra '\ n' e '\ r \ n'

Compatibilità con le versioni precedenti.

Windows è retrocompatibile con MS-DOS (in modo aggressivo, persino) e MS-DOS utilizzava la convenzione CR-LF perché MS-DOS era compatibile con CP / M-80 (un po 'per caso) che utilizzava il CR-LF convenzione perché era così che si guidava una stampante (perché le stampanti erano in origine macchine da scrivere controllate da computer).

Le stampanti hanno un comando separato per spostare il foglio di una riga su una nuova riga e un comando separato per riportare il carrello (dove è stata montata la carta) sul margine sinistro.

Ecco perché. E, sì, è un fastidio, ma è parte del pacchetto che ha permesso a MS-DOS di conquistare CP / M e Windows 95 di conquistare tutte le altre GUI su DOS e Windows XP di prendere il controllo da Windows 98.

(Nota: le moderne stampanti laser hanno ancora questi comandi perché anch'esse sono retrocompatibili con le stampanti precedenti, in particolare HP lo fa bene)

Per chi non ha familiarità con le macchine da scrivere, ecco un video che mostra come è stata eseguita la digitazione: link . Si noti che la carta viene prima spostata verso l'alto e quindi il carrello viene restituito, anche se si verifica in un semplice movimento. Il ding notificò al dattilografo che la fine era vicina e prepararsi per questo.

Per quanto ne so, questo rimanda ai giorni delle macchine da scrivere.

\r è il ritorno a capo, che è ciò che si sposta dove si sta digitando sulla pagina indietro a sinistra (o a destra se questa è la tua cultura)

\n è una nuova riga, che sposta il tuo foglio su una riga.

Facendo solo uno di questi su una macchina da scrivere ti metterebbe nel posto sbagliato per iniziare a scrivere una nuova riga di testo.

Quando i computer sono arrivati suppongo che alcune persone abbiano mantenuto il vecchio modello, ma altri hanno capito che non era necessario e incapsularono una nuova riga intera come un unico personaggio.

Storicamente, l'avanzamento riga significava che il rullo - il rullo su cui si digita - ruotava una linea, facendo apparire il testo sulla riga successiva ... ma nella colonna successiva.

Ritorno a capo significava "restituisci il bit con cui digiti all'inizio della riga".

Windows usa CR + LF perché MS-DOS lo ha fatto, perché CP / M lo ha fatto, perché aveva senso per le linee seriali.

Unix ha copiato la sua \ n convenzione perché Multics ha fatto.

Sospetto che se riesci a scavare abbastanza indietro, troverai un disaccordo politico tra gli implementatori!

(Hai omesso il bit divertente in più, in cui la convenzione Mac è (o lo era) per usare semplicemente CR per separare le righe e ora anche Unicode ha il proprio separatore di riga, U + 2028!)

Non so se questo è noto, ma va notato che CR è ancora inteso dai moderni emulatori di terminali:

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

È utile per gli indicatori di avanzamento, ad es.

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

Storia del carattere 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.

Che cosa succede alle persone che chiedono "perché Unix può fare \n e non Windows"? È una domanda così strana.

1. Il sistema operativo non ha quasi nulla a che fare con questo. È più una questione di come app, librerie, protocolli e formati di file si occupano di cose. A parte il punto in cui il sistema operativo legge / scrive comandi di configurazione o comandi da riga di testo, non ha senso commettere errori nel sistema operativo.
2. La maggior parte delle app di Windows può leggere sia \n che \r\n bene. Hanno anche prodotto \r\n in modo che tutti siano felici. Un programma non "fa" semplicemente \n o \r\n - accetta uno, l'altro o entrambi e restituisce l'uno, l'altro, o entrambi.
3. Come programmatore questo dovrebbe quasi mai infastidirti. Praticamente ogni lingua / piattaforma ha le possibilità di scrivere la linea di fine corretta e leggere più efficacemente. L'unica volta che ho avuto a che fare con il problema è stato quando ho scritto un server HTTP - e era perché un certo browser (suggerimento: il prossimo browser più popolare dopo IE) stava facendo \n invece di il corretto \r\n .
4. Una domanda molto più pertinente è, perché tante app moderne di Unix producono solo \n pienamente sapendo che ci sono alcuni protocolli e programmi a cui non piace?

Il motivo per cui le convenzioni mantengono i loro vari sistemi (\ n su sistemi di tipo unix, \ r \ n su Windows, ecc.) è che una volta che hai scelto una convenzione NON puoi cambiarla senza rompere un gruppo di persone File. E questo è generalmente disapprovato.

I sistemi di tipo Unix sono stati sviluppati (molto presto) usando vari modelli di telescrivente e, a un certo punto, qualcuno ha deciso che l'attrezzatura doveva tornare a capo quando faceva un avanzamento di riga.

Windows proveniva da DOS, quindi per Windows la domanda è davvero: perché DOS ha usato questa sequenza cr / lf? Immagino che abbia qualcosa a che fare con CP / M, dove DOS ha alcune delle sue radici. Ancora una volta, specifici modelli di teletype potrebbero aver avuto un ruolo.

Ecco una risposta dalla migliore fonte: Microsoft. Perché il terminatore di riga 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.