Pourquoi Linux utilise LF comme caractère de nouvelle ligne?
Pour autant que je sache, chaque système d'exploitation a une manière différente de marquer le caractère de fin de ligne (EOL). Les systèmes d'exploitation commerciaux utilisent le retour chariot pour EOL (retour chariot et saut de ligne sous Windows, retour chariot uniquement sur Mac). Linux, d'autre part, utilise simplement 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 CRLF car il l'a hérité de MS-DOS.
MS-DOS utilise CRLF parce qu'il était inspiré par CP/M qui utilisait déjà CRLF.
CP/M et de nombreux systèmes d'exploitation des années 80 et antérieurs utilisés CRLF parce que c'était le moyen de terminer une ligne imprimée sur un téléscripteur (revenir au début de la ligne et passer à la ligne suivante, tout comme les machines à écrire normales). Cela a simplifié l'impression d'un fichier car il y avait moins ou pas de prétraitement requis. Il y avait également des exigences mécaniques qui empêchaient qu'un seul caractère soit utilisable. Un certain temps peut être nécessaire pour permettre au chariot de revenir et à la platine de tourner.
Gnu/Linux utilise LF car c'est un Unix clone . 1
Unix a utilisé un seul caractère, LF, dès le début pour économiser de l'espace et normaliser en une fin de ligne canonique, l'utilisation de deux caractères était inefficace et ambiguë. Ce choix a été hérité de Multics qui l'a utilisé dès 1964. La mémoire, le stockage, la puissance du processeur et la bande passante étaient très rares, donc économiser un octet par ligne en valait la peine. Lors de l'impression d'un fichier, le pilote convertissait le saut de ligne (nouvelle ligne) en caractères de contrôle requis par le périphérique cible.
LF a été préféré à CR car ce dernier avait encore un usage spécifique. En repositionnant le caractère imprimé au début de la même ligne, il a permis de surimprimer les caractères déjà tapés.
Apple a d'abord décidé d'utiliser également un seul caractère, mais pour une raison quelconque, il a choisi l'autre: CR. Lorsqu'il est passé à une interface BSD, il est passé à LF.
Ces choix n'ont rien à voir avec le fait qu'un OS soit commercial ou non.
1 Ceci est la réponse à votre question.
L'article de wikipedia sur "Newline" retrace le choix de NL comme terminateur de ligne (ou séparateur) pour Multics en 1964; malheureusement, l'article contient peu de références aux sources, mais il n'y a aucune raison de douter que ce soit correct. Il y a deux avantages évidents à ce choix par rapport au CR-LF: économie d'espace et indépendance de l'appareil.
La principale alternative, CR-LF, trouve son origine dans les codes de commande utilisés pour déplacer physiquement le chariot papier sur une machine de téléscripteur, où CR ramènerait le chariot à sa position d'origine et LF ferait tourner le rouleau de papier pour déplacer la position d'impression d'une ligne vers le bas. Les deux caractères de contrôle apparaissent dans le code ITA2 qui remonte à 1924 et qui est apparemment toujours utilisé (voir Wikipedia); apparemment ITA2 les a empruntés à la variante Murray du code Baudot qui date à 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 était plutôt une séquence d'enregistrements qui étaient soit de longueur fixe (souvent 80 caractères, basés sur des cartes perforées), soit 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 composé d'une séquence d'enregistrements de longueur variable contenant chacun un contenu binaire arbitraire, la conversion sans perte en un fichier de style UNIX peut être une conversion délicate.
Linux, bien sûr, n'était qu'une réimplémentation d'Unix, et Unix a pris bon nombre de ses décisions de conception de Multics, il semble donc que la décision clé ait été prise en 1964.
D'autres réponses ont retracé la chaîne d'héritage dans les années 1960 et les télétypes. Mais voici un aspect qu'ils n'ont pas couvert.
À l'époque des télétypes, il y avait des moments où il était souhaitable de faire quelque chose qui s'appelle la surcharge. La surimpression était parfois utilisée pour masquer un mot de passe, car l'effacement du mot de passe n'était tout simplement pas faisable. D'autres fois, une surcharge a été effectué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.
. Pour cette raison, le peuple Unix a décidé de ne pas utiliser le retour chariot comme séparateur de ligne et a plutôt opté pour le saut de ligne. Cela a également bien fonctionné pour la lecture de textes produits à l'aide de 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 must utilisent LF (ou du moins quel que soit le C '\n' est) car la nouvelle ligne est une conséquence de l'intersection des exigences de C et POSIX. Alors que C permet 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 avoir '\n' traduit vers/depuis CR/LF comme sous DOS/Windows), POSIX impose que le 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 comme cat sont puissants/utiles; ils le seraient beaucoup moins s'ils ne travaillaient qu'avec du binaire, ou seulement avec du texte, mais pas les deux.