Pourquoi Linux utilise-t-il LF comme caractère de nouvelle ligne?

Autant que je sache, chaque système d'exploitation utilise une méthode différente pour marquer le caractère de fin de ligne (EOL). Les systèmes d'exploitation commerciaux utilisent retour chariot pour EOL (retour chariot et saut de ligne sous Windows, retour chariot uniquement sous Mac). Linux, d’autre part, utilise uniquement le saut de ligne pour EOL.

Pourquoi Linux n'utilise-t-il pas le retour chariot pour EOL (et uniquement le saut de ligne)?

Windows utilise CRLFparce qu'il a hérité de MS-DOS.

MS-DOS utilise CRLFparce qu’il a été inspiré par CP / M qui l’utilisait déjà CRLF.

CP / M et de nombreux systèmes d’exploitation datant des années 80 et antérieures ont été utilisés CRLFparce que c’était le moyen de terminer une ligne imprimée sur un télétype (revenez au début de la ligne et passez à la ligne suivante, comme pour les machines à écrire classiques). Ceci simplifie l’impression d’un fichier car aucun pré-traitement n’est requis, voire nul. Il y avait aussi des exigences mécaniques qui empêchaient un seul personnage d'être utilisable. Il faudra peut-être un peu de temps pour permettre au chariot de revenir et à la rotation de la platine.

Gnu / Linux utilise LFparce qu’il s’agit d’un clone Unix . ¹

Unix utilisait un seul caractère, LFdès le départ pour gagner de la place et se normaliser sur une fin de ligne canonique, utiliser deux caractères était inefficace et ambigu. Ce choix a été hérité de Multics, qui l’utilisait dès 1964. La mémoire, le stockage, la puissance du processeur et la bande passante étaient très rares, il était donc avantageux d’économiser un octet par ligne. Lorsqu'un fichier était imprimé, le pilote convertissait le saut de ligne (nouvelle ligne) en caractères de contrôle requis par le périphérique cible.

LFa été préféré à CRparce que ce dernier avait encore un usage spécifique. En repositionnant le caractère imprimé au début de la même ligne, cela permettait de surimprimer les caractères déjà saisis.

Apple a décidé d' abord d'utiliser également un caractère unique , mais pour une raison quelconque a pris l'autre: CR. Lorsqu'il est passé sur une interface BSD, il est passé à LF.

Ces choix n'ont rien à voir avec le fait qu'un système d'exploitation est commercial ou non.

¹ Ceci est la réponse à votre question.

L'article de Wikipédia sur "Newline" explique le choix de NL comme terminateur de ligne (ou séparateur) par Multics en 1964; Malheureusement, l'article contient peu de citations dans les sources, mais il n'y a aucune raison de douter que cela soit correct. Ce choix présente deux avantages évidents par rapport au CR-LF: un gain de place et l’indépendance de l’appareil.

La principale alternative, CR-LF, provient des codes de contrôle utilisés pour déplacer physiquement le chariot de papier sur un télécopieur, où CR ramènerait le chariot à sa position initiale et LF ferait pivoter le rouleau de papier pour déplacer la position d'impression vers le bas. ligne. Les deux caractères de contrôle apparaissent dans le code ITA2, datant de 1924 et apparemment toujours utilisé (voir Wikipedia); apparemment, ITA2 les a empruntés à la variante Murray du code Baudot, datant de 1901.

Pour les jeunes lecteurs, il convient de noter que dans la tradition du mainframe, il n’y avait pas de caractère de nouvelle ligne; un fichier est plutôt une séquence d'enregistrements de longueur fixe (souvent 80 caractères, basés sur des cartes perforées) ou de longueur variable; Les enregistrements de longueur variable étaient généralement stockés avec un nombre de caractères au début de chaque enregistrement. Si vous avez un fichier mainframe constitué d'une séquence d'enregistrements de longueur variable contenant chacun un contenu binaire arbitraire, la conversion de ce fichier sans perte en un fichier de style UNIX peut s'avérer délicate.

Linux, bien sûr, n’était qu’une nouvelle implémentation d’Unix, et Unix a pris de nombreuses décisions de conception de la part de Multics. Il semble donc que la décision clé ait été prise en 1964.

D'autres réponses ont retracé la chaîne de l'héritage jusqu'aux années 1960 et les télétypes. Mais voici un aspect qu'ils n'ont pas abordé.

À l'époque des télétypes, il était parfois souhaitable de faire quelque chose qui s'appelle une surimpression. Le fait de surcharger a parfois été utilisé pour masquer un mot de passe, car son effacement n’était tout simplement pas faisable. D'autres fois, la surimpression était utilisée pour obtenir un symbole qui n'était pas dans la police. Par exemple, la lettre O et une barre oblique produisent un nouveau symbole.
La surexploitation a été obtenue en introduisant un retour chariot sans saut de ligne, même si un retour arrière a parfois été utilisé. Pour cette raison, les utilisateurs Unix ont décidé de ne pas retourner chariot comme séparateur de ligne et ont opté pour un saut de ligne. Cela a également bien fonctionné pour la lecture de textes produits avec la convention CRLF. Le CR est avalé et le LF devient le séparateur.

Bien que vous puissiez traduire la question historique en une question sur le langage C, la raison pour laquelle Linux et tous les systèmes conformes à POSIX ou POSIX-ish doit utiliser LF(ou au moins quel que soit le '\n'caractère C ) car la nouvelle ligne est une conséquence de l'intersection des exigences de C et POSIX. Bien que C permette aux "fichiers texte" et aux "fichiers binaires" de différer (en fait, les fichiers texte peuvent être basés sur des enregistrements, consistant en une séquence d’enregistrements de ligne, en plus de choses moins exotiques, comme la '\n'traduction en / de CR/ LFsimilaire à DOS / Windows ), POSIX exige que le mode texte et le mode binaire se comportent de la même manière. C’est en grande partie la raison pour laquelle les outils de ligne de commande tels quecatsont puissants / utiles; ils le seraient beaucoup moins s'ils ne travaillaient qu'avec du binaire, ou seulement du texte, mais pas les deux.