Dlaczego Linux używa LF jako znaku nowej linii?

87

O ile mi wiadomo, każdy system operacyjny ma inny sposób oznaczania znaku końca linii (EOL). Komercyjne systemy operacyjne używają powrotu karetki dla EOL (powrót karetki i przesunięcie wiersza w systemie Windows, powrót karetki tylko w systemie Mac). Z drugiej strony Linux używa po prostu linii do EOL.

Dlaczego Linux nie używa znaku powrotu karetki dla EOL (i zamiast tego tylko przesuwania wiersza)?

Bagas Sanjaya
źródło
77
Komputery Mac nie używały CR tylko od czasu wcześniejszego niż OS X ... teraz używam LF w stylu * nix, jak sądzę.
Warstwa B,
33
Wydaje mi się, że istnieje / było także wiele komercyjnych systemów operacyjnych Unixy.
ilkkachu
20
Wyjaśnione na Wikipedii . Zasadniczo Multics w ostatnich latach 60. (który zainspirował Unixa, który zainspirował Linuksa) dodał pewien poziom abstrakcji, aby uniknąć obciążania kodowania tekstu ograniczeniami urządzeń typu teletekstu, więc nie musiał kodować nowej linii na dwóch znakach (co czyni nawet mniej sens 50 lat później oczywiście).
Stéphane Chazelas,
74
Drugi akapit jest ważnym pytaniem, ale pierwszy akapit jest tak pełen uproszczeń i oczywistych błędów, że zagłusza go, a autorzy muszą skorygować całą masę niepewnych i wadliwych przesłanek, zanim jeszcze przejdą do pytania.
JdeBP,
21
Co? Linux to bezpłatne przybliżenie komercyjnego standardu systemu operacyjnego o nazwie UNIX. Systemy zgodne z UNIXem kosztują wtedy dużo pieniędzy i nadal to robią.
errantlinguist,

Odpowiedzi:

334

System Windows używa, CRLFponieważ odziedziczył go po MS-DOS.

MS-DOS używa, CRLFponieważ został zainspirowany przez CP / M, który był już używany CRLF.

Wykorzystano CP / M i wiele systemów operacyjnych z lat osiemdziesiątych i wcześniejszych, CRLFponieważ był to sposób na zakończenie linii wydrukowanej na teletypie (powrót na początek linii i przejście do następnej linii, tak jak zwykłe maszyny do pisania). Uprościło to drukowanie pliku, ponieważ wstępne przetwarzanie było mniejsze lub nie było wymagane. Istniały również wymagania mechaniczne, które uniemożliwiały użycie jednego znaku. Może zająć trochę czasu, aby umożliwić powrót karetki i obrót płyty dociskowej.

GNU / Linux używa, LFponieważ jest to klon uniksowy . 1

Unix używał jednego znaku, LFod samego początku, aby zaoszczędzić miejsce i ustandaryzować do kanonicznego końca linii, użycie dwóch znaków było nieefektywne i dwuznaczne. Ten wybór został odziedziczony po Multics, który używał go już w 1964 roku. Pamięć, pamięć, moc procesora i przepustowość były bardzo rzadkie, więc warto było zaoszczędzić jeden bajt na linię. Gdy plik został wydrukowany, sterownik konwertuje przesunięcie wiersza (nowa linia) na znaki sterujące wymagane przez urządzenie docelowe.

LFbył preferowany, CRponieważ ten ostatni nadal miał określone zastosowanie. Przesunięcie drukowanego znaku na początek tego samego wiersza pozwoliło na zastąpienie już wpisanych znaków.

Jabłko początkowo postanowił również użyć pojedynczego znaku, ale z jakiegoś powodu wybrał drugą: CR. Kiedy przeszedł na interfejs BSD, przeniósł się do LF.

Te wybory nie mają nic wspólnego z faktem, że system operacyjny jest komercyjny czy nie.

1 To jest odpowiedź na twoje pytanie.

jlliagre
źródło
20
Multics zastosował Line Feed w zgodzie ze współczesną normą ISO / IEC 646, która wyznaczyła go jako sposób reprezentowania zarówno powrotu karetki, jak i linii, za pomocą jednego znaku, jeśli potrzebna jest reprezentacja jednoznakowa.
JdeBP,
10
Wątpię, aby prawdziwym powodem wyboru jednej postaci była oszczędność miejsca. Prawdziwym powodem było zdefiniowanie pojedynczego znaku nowej linii, który jest niezależny od urządzenia wyjściowego (terminal itp.). Sterownik terminalu (lub podobny) zajmuje się następnie konwersją nowej linii na odpowiednią sekwencję znaków kontrolnych, zwykle CR LF. Pozwala to na ładną abstrakcję podczas programowania przy pomocy ciągów: nowa linia jest prezentowana z pojedynczym \n, niezależnie od określonego urządzenia wyjściowego.
Johan Myréen,
14
Niemniej jednak praca z 1970 r. Autorstwa Saltzera i Ossanny ( Zdalne przetwarzanie strumienia znaków terminalu w Multics ) jasno pokazuje, że powodem była niezależność urządzenia .
JdeBP,
3
@JdeBP Artykuł ten stanowi redukcję kanonicznej postaci strumienia znaków przechodzących do i ze zdalnych terminali jest przedmiotem tego artykułu . Sprowadzenie do formy kanonicznej było również sposobem na zaoszczędzenie miejsca. Inaczej mówiąc, użycie dwóch znaków było nieefektywnym i niejednoznacznym marnotrawstwem miejsca.
jlliagre,
46
Teletypy otrzymały to od nieelektrycznych maszyn do pisania. CR-LF opisuje działanie mechaniczne podejmowane po naciśnięciu dźwigni po lewej stronie. Zwróć „karetkę”, która przytrzymuje płytę dociskową (rolkę) do końca w prawo (co powoduje wciśnięcie klawisza w pierwszej pozycji po lewej stronie) i obróć płytę o jedną linię wysokości, aby przejść do następnej linii do pisania. Tak, co prawda pokazuję tutaj swój wiek.
cdkMoose,
17

Artykuł w Wikipedii na temat „Newline” śledzi wybór NL jako terminatora (lub separatora) linii do Multics w 1964 roku; niestety artykuł zawiera kilka cytatów do źródeł, ale nie ma powodu, by wątpić, czy to prawda. Istnieją dwie oczywiste zalety tego wyboru w porównaniu z CR-LF: oszczędność miejsca i niezależność urządzenia.

Główna alternatywa, CR-LF, pochodzi od kodów sterujących używanych do fizycznego przesunięcia karetki papieru na maszynie teletechnicznej, gdzie CR przywróciłoby karetkę do pozycji wyjściowej, a LF obrócił rolkę papieru, aby przesunąć pozycję drukowania w dół o jeden linia. Dwa znaki kontrolne pojawiają się w kodzie ITA2, który pochodzi z 1924 r. I który najwyraźniej jest nadal używany (patrz Wikipedia); najwyraźniej ITA2 wzięło je z wariantu kodu Baudot Murraya z 1901 r.

Dla młodszych czytelników warto zauważyć, że w tradycji komputerów mainframe nie było znaku nowej linii; raczej plik był sekwencją zapisów, które miały albo stałą długość (często 80 znaków, w oparciu o karty perforowane), albo zmienną długość; zapisy o zmiennej długości były zwykle przechowywane z liczbą znaków na początku każdego zapisu. Jeśli masz plik mainframe składający się z sekwencji rekordów o zmiennej długości, z których każda zawiera dowolną zawartość binarną, konwersja tego pliku bezstratnie do pliku w stylu UNIX może być trudną konwersją.

Linux oczywiście był tylko ponowną implementacją Uniksa, a Unix podjął wiele decyzji projektowych od Multics, więc wygląda na to, że kluczowa decyzja została podjęta w 1964 roku.

użytkownik32929
źródło
12

Inne odpowiedzi prześledziły łańcuch spadkowy z lat 60. XX wieku i rodzaje teletekstów. Ale jest jeden aspekt, którego nie omówili.

W czasach teletypów były chwile, w których pożądane było zrobienie czegoś zwanego overstrike. Overstrike bywało czasem używane do ukrywania hasła, ponieważ usunięcie hasła było po prostu niewykonalne. Innym razem wykonywano nadpisywanie, aby uzyskać symbol, którego nie ma w czcionce. Na przykład litera O i ukośnik tworzą nowy symbol.
Overstriking został osiągnięty poprzez wprowadzenie powrotu karetki bez linii posuwu, czasem użyto mocnego backspace. Z tego powodu ludzie uniksowi zdecydowali się nie zwracać karetki jako separatora linii i zamiast tego zdecydowali się na podawanie linii. Sprawdziło się to również w przypadku czytania tekstów wyprodukowanych przy użyciu konwencji CRLF. CR zostaje połknięty, a LF staje się separatorem.

Walter Mitty
źródło
Dziękuję za tę dokładną pamięć. Backspace i Carriage Return (same) były również używane w drukarce do tworzenia pogrubionych lub podkreślonych znaków. Aby powrócić do początków, te dwa polecenia istniały już w 1930 r., Aby „powóz” „powrócił” do skrajnie lewej pozycji, albo zaatakować, albo zezwolić na rozpoczęcie nowej linii za pomocą „nowej linii” klucz, który spowodował obrót rolki o jeden krok. Zobacz: en.wikipedia.org/wiki/IBM_Electric_typewriter . Tak więc „CR” + „LF” umawiają się przed historią komputerów.
dn
Warto również zauważyć, że niektóre typy teletekstów wymagały, aby po CR pojawił się znak niedrukowalny, aby dać czas na pełne przejście karetki przed nadejściem następnego znaku drukującego, i w ogóle nie obsługiwał odstępu wstecznego, więc wysyłanie LF po CR nic nie kosztowało, a jedynym sposobem na nadruk był CR.
supercat
„Dni teletypów” rozpoczynają się przed erą komputerów. w latach sześćdziesiątych wiele komputerów miało teletyp konsoli dla operatora, a jeszcze więcej używało ASCII jako zestawu znaków.
Walter Mitty,
7

Chociaż możesz przetłumaczyć pytanie historyczne na pytanie dotyczące języka C, powód, dla którego Linux i wszystkie systemy zgodne z POSIX lub POSIX-owe muszą używać LF(lub przynajmniej cokolwiek to '\n'jest znak C ) jako nowej linii, jest konsekwencją przecięcia wymagań C i POSIX. Podczas gdy C umożliwia różnicowanie „plików tekstowych” i „plików binarnych” (w rzeczywistości pliki tekstowe mogą być oparte na rekordach składających się z sekwencji rekordów liniowych, oprócz mniej egzotycznych rzeczy, takich jak '\n'tłumaczenie na / z CR/ LFjak na DOS / Windows ), POSIX nakazuje, aby tryb tekstowy i binarny zachowywał się tak samo. Jest to w dużej mierze powód, dla którego lubią narzędzia wiersza poleceńcatsą potężne / przydatne; byłoby ich znacznie mniej, gdyby pracowali tylko z plikiem binarnym lub tylko z tekstem, ale nie z oboma.

R ..
źródło
13
Ten wybór wyprzedza POSIX o wiele lat. Jak wspomniano w odpowiedzi jlliagre, wraca do początku Uniksa, który skopiował go z Multics.
Barmar,
4
Wybór w Linuksie nie wyprzedza POSIX o wiele lat. Oczywiście POSIX skodyfikował istniejącą już praktykę, ponieważ był to jedyny powód jej istnienia.
R ..
Jeśli chodzi o Linuksa, to nie było prawdziwego wyboru. Standardowa biblioteka Gnu, która jest używana przez Linuksa, jest współczesna POSIX i od początku była używana z liniowym zasilaniem z oczywistych powodów kompatybilności, ponieważ została opracowana, przetestowana i użyta w systemach Unix. Jądro Linux zostało zaprojektowane w celu zapewnienia wywołań systemowych podobnych do Uniksa do standardowej biblioteki C (GNU lub innej), a dodanie złożoności wymaganej do obsługi różnych plików tekstowych i plików binarnych byłoby nadmierne i łamałoby kompatybilność z istniejącym kodem. To byłoby nonsensowne od Torvaldsa.
jlliagre
@jlliagre: Nadal wybór padł na coś zgodnego z istniejącymi praktykami, a nie przypadkowe nieuzasadnione niezgodności. Można tylko powiedzieć, że nie był to wybór w kontekście zakładania sukcesu Linuksa. Wiele osób dokonuje hobbystycznych zabawek w systemie operacyjnym pełnym niepotrzebnie szalonych wyborów i nigdzie się nie wybierają.
R ..
@RI oznacza, że ​​Linux jest tylko jądrem i zasadniczo wymagał GNU do działania (początkowo celem Torvaldsa była kompatybilność z minixem zamiast GNU, ale to nie ma znaczenia tutaj). Wybór nowej linii nie jest związany z Linuksem, ponieważ został dokonany na długo przed napisaniem Linuksa. W różnych wydaniach Linuksa było wiele mniej lub bardziej zwariowanych wyborów, nie powstrzymały one sukcesu Linuxa. Jednym z powodów prawdopodobnie późniejszej weryfikacji wielu z tych wyborów.
jlliagre