Motivo storico dietro diverse linee che terminano su piattaforme diverse

Question

Perché DOS / Windows e Mac hanno deciso di utilizzare \ r \ n e \ r per la fine della linea anziché \ n? È stato solo il risultato del tentativo di essere "diverso"? da Unix?

E ora che Mac OS X è Unix (-like), Apple è passata a \ n da \ r?

Answer 1

Terminazioni di riga CR-LF ereditate da DOS (ciò che stai chiamando \ r \ n, rendendo espliciti i caratteri ASCII) da CP / M. CP / M l'ha ereditato dai vari sistemi operativi DEC che hanno influenzato il designer di CP / M Gary Kildall.

CR-LF è stato utilizzato in modo che le macchine del teletipo restituissero la testina di stampa sul margine sinistro (CR = ritorno a capo), quindi si sposta sulla riga successiva (LF = avanzamento riga).

I ragazzi di Unix lo hanno gestito nel driver del dispositivo e, quando necessario, hanno tradotto LF in CR-LF in uscita su dispositivi che ne avevano bisogno.

E come hai indovinato, Mac OS X ora utilizza LF.

Answer 2

In realtà aggiungendo a @Mark Harrison ...

Le persone che ti dicono che Unix sta semplicemente pubblicando il testo specificato dal programmatore " mentre DOS è rotto sono chiaramente sbagliati. Ci sono anche affermazioni che è stupido per DOS segnalare EOF quando vede un personaggio EOF, sollevando la questione di cosa sia esattamente quel personaggio EOF.

Non esiste una vera convenzione per le terminazioni di riga dei file di testo: solo convenzioni specifiche della piattaforma. Dopotutto, anche CR-LF, CR e LF non sono le uniche convenzioni di fine riga mai usate, e ASCII non è mai stato nemmeno il solo e unico set di caratteri. Il problema è la libreria standard C e il runtime, che non ha sottratto questo dettaglio dipendente dalla piattaforma. Altre lingue di terza generazione (come Pascal e persino Basic) lo gestirono, almeno in una certa misura. Per questo motivo, quando i compilatori C venivano scritti per altre piattaforme, erano necessari hack delle librerie di runtime per ottenere la compatibilità con il codice sorgente e i libri esistenti.

In effetti, è Unix e Multics che originariamente avevano bisogno della traduzione di stringhe per l'I / O della console, poiché gli utenti di solito si sedevano su un terminale ASCII che richiedeva la fine della linea CR LF. Questa traduzione è stata fatta in un driver di dispositivo, tuttavia: l'obiettivo era quello di sottrarre le specifiche del dispositivo, supponendo che fosse meglio adottare una convenzione e attenersi ad essa per i file di testo memorizzati.

L'hacking I / O del testo C è simile in linea di principio a quello che fa CygWin ora, hackerando i runtime di Linux per funzionare così come ci si può aspettare su Windows. C'è una vera storia di hacking di cose per trasformarle in Unix-simili - ma poi c'è anche Wine, che trasforma Linux in Windows. Stranamente, puoi leggere alcune critiche di fine riga fuori posto di Windows nel Domande frequenti su CygWin (collegamento Internet Archive aggiunto 2013 - la pagina non esiste più). Forse è solo il loro senso dell'umorismo, dal momento che praticamente stanno facendo ciò che stanno criticando, ma su una scala molto più grande ;-)

La libreria standard C ++ (qualunque sia la piattaforma su cui è stata implementata) evita questo problema usando gli iostreams, che terminano in modo astratto. Per l'output, mi va bene. Per l'input, ho bisogno di un maggiore controllo, quindi interpreto carattere per carattere oppure uso un generatore di scanner.

[ MODIFICA Si scopre che la rivendicazione cancellata sopra non è vera, e non lo è mai stata. std :: endl si traduce letteralmente in \ n e in flush. Il \ n è esattamente lo stesso \ n che ottieni in C - tende a essere chiamato " nuova linea " ;, ma in realtà è un carattere di avanzamento di riga ASCII, che quindi viene tradotto dal runtime, se necessario. Divertente come i presupposti falsi possano essere così radicati che non li metti mai in discussione - fondamentalmente, C ++ non ha avuto scelta di fare ciò che C ha fatto (oltre ad aggiungere più livelli in cima) per motivi di compatibilità, e questo avrebbe dovuto essere sempre ovvio.]

La più grande fetta di colpa dal mio POV è con C, ma C non è l'unico progetto a non riuscire ad anticipare il suo passaggio ad altre piattaforme. Incolpare Bill Gates è semplicemente pazzo: tutto ciò che ha fatto è stato acquistare e lucidare una variante dell'allora popolare CP / M. In realtà, è solo la storia, lo stesso motivo per cui non sappiamo a quali codici dei caratteri da 128 a 255 faccia riferimento nella maggior parte dei file di testo. Data la facilità di far fronte a tutte e tre le convenzioni di fine linea, è strano che alcuni sviluppatori insistano ancora sul fatto che "la mia convenzione sulle piattaforme è l'unico vero modo, e la costringerò a piacervi o meno" atteggiamento.

Inoltre - il separatore di riga Unicode codepoint U + 2028 sostituirà tutte queste convenzioni in futuri file di testo? ; -)

Answer 3

C'è un articolo piuttosto lungo sulle terminazioni di riga su Wikipedia. La " Storia " la sezione risponde almeno in parte alla tua domanda: http://en.wikipedia.org/wiki/Newline# storia

Answer 4

È interessante notare che il CRLF è praticamente lo standard Internet. Cioè, praticamente ogni protocollo Internet standard che è orientato alla linea utilizza CRLF. SMTP, POP, IMAP, NNTP, ecc. Il corpo dell'e-mail è costituito da linee terminate da CRLF.