Raison historique derrière différentes lignes se terminant sur différentes plateformes

Question

Pourquoi DOS / Windows et Mac ont-ils décidé d’utiliser \ r \ n et \ r pour les fins de ligne au lieu de \ n? Était-ce simplement le résultat d'essayer d'être "différent"? depuis Unix?

Et maintenant que Mac OS X est sous Unix (semblable à celui-ci), Apple est-il passé de \ n à partir de \ r?

Answer 1

Les fins de ligne héritées du DOS en CR-LF (ce que vous appelez \ r \ n, en expliquant simplement les caractères ascii) à partir de CP / M. CP / M l'a hérité des différents systèmes d'exploitation DEC qui ont influencé le concepteur de CP / M, Gary Kildall.

CR-LF a été utilisé pour que les télécopieurs ramènent la tête d'impression à la marge gauche (CR = retour chariot), puis à la ligne suivante (LF = saut de ligne).

Les gars d'Unix ont géré cela dans le pilote de périphérique et, le cas échéant, ont converti LF en CR-LF à la sortie des périphériques qui en avaient besoin.

Et comme vous l'avez deviné, Mac OS X utilise maintenant le mode LF.

Answer 2

Ajouter vraiment à @Mark Harrison ...

Les personnes qui vous disent qu'Unix "sort seulement le texte spécifié par le programmeur" alors que DOS est cassé sont tout simplement faux. Certains prétendent également que c’est stupide pour DOS de signaler EOF quand il voit un caractère EOF, ce qui pose la question de savoir à quoi sert exactement ce caractère.

Il n’existe pas de convention unique en ce qui concerne les fins de ligne de fichier texte, mais uniquement des conventions spécifiques à la plate-forme. Après tout, même CR-LF, CR et LF ne sont pas les seules conventions d’extrémité de ligne jamais utilisées, et ASCII n’a jamais été le seul et unique jeu de caractères. Le problème réside dans la bibliothèque et le moteur d'exécution standard C, qui n'ont pas fait abstraction de ces détails dépendants de la plate-forme. D'autres langages de troisième génération (tels que Pascal et même Basic) l'ont géré, du moins dans une certaine mesure. Pour cette raison, lorsque les compilateurs C étaient écrits pour d'autres plates-formes, des piratages de bibliothèque d'exécution étaient nécessaires pour assurer la compatibilité avec le code source et les livres existants.

En fait, c’est à l’origine Unix et Multics qui nécessitait à l’origine une traduction de chaîne pour les E / S de la console, car les utilisateurs étaient généralement assis à un terminal ASCII qui nécessitait des fins de ligne CR LF. Cette traduction a toutefois été effectuée dans un pilote de périphérique - le but était d'extraire les spécificités de périphérique, en supposant qu'il était préférable d'adopter une convention et de s'y tenir pour les fichiers texte stockés.

Le hack d’E / S en C texte est semblable dans son principe à ce que CygWin fait maintenant, piratant les runtimes Linux pour fonctionner aussi bien que ce à quoi on peut s’attendre sous Windows. Il y a une longue histoire de piratage de choses sur le point de les transformer en Unix, mais il y a aussi Wine, qui transforme Linux en Windows. Curieusement, vous pouvez lire des critiques mal placées de Windows sur les fins de ligne dans le fichier FAQ de CygWin (lien Internet Archive ajouté en 2013 - la page n'existe plus). Peut-être que c'est juste leur sens de l'humour, puisqu'ils font essentiellement ce qu'ils critiquent, mais à une échelle beaucoup plus grande ;-)

La bibliothèque standard C ++ (quelle que soit la plate-forme sur laquelle il est implémenté) évite ce problème en utilisant iostreams, qui se termine par une ligne abstraite. Pour la sortie, cela me convient parfaitement. Pour pouvoir entrer, j'ai besoin de plus de contrôle, donc j'interprète caractère par caractère ou j'utilise un générateur de scanner.

[ MODIFIER ) Il s'avère que la revendication rayée ci-dessus n'est pas vraie et ne l'a jamais été. std :: endl se traduit littéralement par un \ n et un flush. Le \ n est exactement le même \ n que vous obtenez en C - il a tendance à s'appeler "nouvelle ligne", mais c'est en fait un caractère de saut de ligne ASCII, qui est traduit par le runtime si nécessaire. C'est drôle de voir que de fausses hypothèses peuvent être tellement enracinées que vous ne les remettez jamais en cause - C ++ n'avait fondamentalement pas le choix de faire ce que C (sauf d'ajouter plus de couches au-dessus) pour des raisons de compatibilité, et cela aurait toujours dû être évident.]

La plus grande part de blâme de mon point de vue est avec C, mais C n’est pas le seul projet à ne pas anticiper son passage à d’autres plateformes. Blâmer Bill Gates n’est que fou: tout ce qu’il a fait est d’acheter et de peaufiner une variante du très populaire CP / M. En réalité, il ne s’agit que d’historique - la même raison pour laquelle nous ne savons pas à quels codes de caractères 128 à 255 font référence dans la plupart des fichiers texte. Etant donné la facilité avec laquelle sont gérées les trois conventions de fin de ligne, il est étrange que certains développeurs insistent encore sur le fait que "la convention de mes plates-formes est la seule vraie solution, et je vous la forcerai autant que vous le souhaitiez". attitude.

De plus, le séparateur de lignes Unicode codepoint U + 2028 remplacera-t-il toutes ces conventions dans les futurs fichiers texte? ; -)

Answer 3

Il existe un article assez long sur les fins de ligne sur wikipedia. Le " Histoire " Cette section répond au moins en partie à votre question: http://en.wikipedia.org/wiki/Newline# Histoire

Answer 4

Il est intéressant de noter que le CRLF est à peu près le standard Internet. C'est-à-dire que pratiquement tous les protocoles Internet standard orientés ligne utilisent CRLF. SMTP, POP, IMAP, NNTP, etc. Le corps du courrier électronique est constitué de lignes terminées par CRLF.