Почему Linux использует LF в качестве символа новой строки?

87

Насколько я знаю, в каждой операционной системе есть свой способ обозначения символа конца строки (EOL). Коммерческие операционные системы используют возврат каретки для EOL (возврат каретки и перевод строки в Windows, возврат каретки только в Mac). Linux, с другой стороны, просто использует перевод строки для EOL.

Почему Linux не использует возврат каретки для EOL (и вместо этого только перевод строки)?

Багас Санджая
источник
77
Mac не использовал CR только с тех пор, как до OS X ... теперь, я думаю, используется стиль * nix LF.
Уровень B
33
Я думаю, что есть / было много коммерческих ОС Unixy тоже.
ilkkachu
20
Объяснил в Википедии . В основном Multics в последние 60-е годы (который вдохновил Unix, который вдохновил Linux) добавил некоторый уровень абстракции, чтобы избежать того, чтобы кодировка текста была обременена ограничениями устройств телетайпа, чтобы не пришлось кодировать символ новой строки на двух символах (что делает еще меньше смысл спустя 50 лет конечно).
Стефан
74
Второй абзац является действительным вопросом, но первый абзац настолько полон упрощений и откровенных ошибок, что заглушает его, и ответчикам приходится исправлять целую кучу сомнительных и ошибочных посылок, прежде чем они дойдут до вопроса.
JdeBP
21
Какая? Linux является свободным приближением коммерческого стандарта ОС под названием UNIX. UNIX-совместимые системы стоили много денег тогда, и они все еще стоят сегодня.
errantlinguist

Ответы:

334

Windows использует, CRLFпотому что она унаследовала его от MS-DOS.

MS-DOS использует, CRLFпотому что он был вдохновлен CP / M, который уже использовал CRLF.

CP / M и многие операционные системы восьмидесятых и более ранних версий использовались CRLFпотому, что это был способ завершить строку, напечатанную на телетайпе (вернуться к началу строки и перейти к следующей строке, как обычные пишущие машинки). Это упростило печать файла, потому что было меньше или не требовалось предварительной обработки. Существовали также механические требования, которые не позволяли использовать один символ. Может потребоваться некоторое время , чтобы каретка вернулась и валик вращался.

Gnu / Linux использует, LFпотому что это клон Unix . 1

Unix использовал один символ, LFс самого начала для экономии места и стандартизации до канонического конца строки, использование двух символов было неэффективным и неоднозначным. Этот выбор был унаследован от Multics, который использовал его еще в 1964 году. Память, память, мощность процессора и пропускная способность были очень скудны, поэтому стоило сэкономить один байт на строку. Когда файл печатался, драйвер преобразовывал перевод строки (новая строка) в управляющие символы, требуемые целевым устройством.

LFбыло предпочтительным, CRпотому что последний все еще имел определенное использование. Перемещая напечатанный символ в начало той же строки, он позволил переопределить уже набранные символы.

Apple , изначально решили использовать один символ , но по каким - то причинам выбрал другую: CR. Когда он переключился на интерфейс BSD, он перешел на LF.

Эти выборы не имеют ничего общего с тем, является ли ОС коммерческой или нет.

1 Это ответ на ваш вопрос.

jlliagre
источник
20
Multics использовал перевод строки в соответствии с современным стандартом ИСО / МЭК 646, который предписывал его как способ представления возврата каретки и перевода строки в одном символе, если необходимо представление в один символ.
JdeBP
10
Я сомневаюсь, что настоящей причиной выбора одного персонажа была экономия места. Реальная причина заключалась в том, чтобы определить один символ новой строки, который не зависит от устройства вывода (терминала и т. Д.). Затем драйвер терминала (или аналогичный) позаботится о преобразовании новой строки в соответствующую последовательность символов управления, обычно CR LF. Это позволяет получить хорошую абстракцию при программировании со строками: символ новой строки представлен одним \n, независимо от определенного устройства вывода.
Йохан Мирен
14
Тем не менее, в статье 1970 года Saltzer и Ossanna ( Обработка потока символов на удаленном терминале в Multics ) совершенно ясно, что причиной была независимость устройства .
JdeBP
3
@JdeBP Эта статья утверждает, что предметом этой статьи является приведение к канонической форме потока символов, передаваемых на удаленные терминалы и от них . Приведение к канонической форме было способом экономии места (тоже). Выражение по-разному, использование двух символов было неэффективной и неоднозначной тратой пространства.
Jlliagre
46
И телетайпы получили это от неэлектрических пишущих машинок. CR-LF описывает механическое действие, которое вы предпринимаете, когда нажимаете на рычаг слева. Верните «каретку», которая удерживает валик (ролик) полностью назад вправо (который ставит нажатие клавиши в первую позицию слева), и проверните вращение валика на одну строчку по высоте, чтобы перейти к следующей печатаемой строке. Да, я правда показываю свой возраст здесь.
cdkMoose
17

В статье в Википедии "Newline" прослеживается выбор NL в качестве ограничителя (или разделителя) строки для Multics в 1964 году; К сожалению, в статье мало ссылок на источники, но нет никаких оснований сомневаться в том, что это правильно. Есть два очевидных преимущества этого выбора по сравнению с CR-LF: экономия места и независимость от устройства.

Основная альтернатива, CR-LF, исходит из управляющих кодов, используемых для физического перемещения каретки на телетайпной машине, где CR возвращает каретку в исходное положение, а LF поворачивает ролик бумаги, чтобы переместить позицию печати вниз на одну позицию. линия. Два управляющих символа появляются в коде ITA2, который датируется 1924 годом и который по-прежнему используется (см. Википедию); по-видимому, ITA2 взяла их из варианта кода Бодо Мюррея, который датируется 1901 годом.

Для более молодых читателей стоит отметить, что в традиции мэйнфреймов не было символа новой строки; скорее, файл представлял собой последовательность записей фиксированной длины (часто 80 символов на основе перфокарт) или переменной длины; Записи переменной длины обычно хранились с количеством символов в начале каждой записи. Если у вас есть файл мэйнфрейма, состоящий из последовательности записей переменной длины, каждая из которых содержит произвольный двоичный контент, преобразование этого файла без потерь в файл в стиле UNIX может быть сложным преобразованием.

Linux, конечно, был просто повторной реализацией Unix, и Unix принял многие из своих проектных решений от Multics, так что похоже, что ключевое решение было принято в 1964 году.

user32929
источник
12

Другие ответы проследили цепочку наследования до 1960-х годов и телетайпы. Но вот один аспект, который они не охватили.

В дни телетайпа были времена, когда было желательно сделать что-то, называемое перенапряжением. Перекрытие иногда использовалось, чтобы скрыть пароль, потому что стереть пароль было просто невозможно. В других случаях, чтобы получить символ, которого не было в шрифте, было сделано переопределение. Например, буква O и косая черта производят новый символ.
Перенапряжение было достигнуто за счет возврата каретки без перевода строки, хотя иногда использовалось обратное расстояние. По этой причине сотрудники Unix отказались от возврата каретки в качестве разделителя строк и вместо этого выбрали перевод строки. Это также хорошо сработало для чтения текстов, созданных с использованием соглашения CRLF. CR проглатывается, а LF становится разделителем.

Уолтер Митти
источник
Спасибо за эту точную память. Backspace и Carriage Return (отдельно) также использовались на принтере для получения жирных или подчеркнутых символов. И чтобы вернуться к истокам, эти две команды уже существовали в 1930 году, чтобы заставить «карету» «возвращаться» в крайнее левое положение, либо для удара, либо для разрешения начать новую линию с помощью «новой линии» ключ, который сделал вращение ролика на один шаг. Смотрите: en.wikipedia.org/wiki/IBM_Electric_typewriter . Так что «CR» + «LF» встречаются еще до компьютерной истории.
дан
Также может быть стоит отметить, что некоторые телетайпы требовали, чтобы за CR следовал непечатный символ, чтобы дать время каретки для полного цикла до прибытия следующего печатного символа, и вообще не поддерживал возврат назад, поэтому отправка LF после CR ничего не стоило, и единственный способ добиться надпечатки был через CR.
суперкат
«Дни телетайпа» начинаются до компьютерной эры. в 1960-х многие компьютеры имели консольный телетайп для оператора, и еще больше использовали ASCII в качестве своего набора символов.
Уолтер Митти
7

В то время как вы могли бы перевести исторический вопрос в вопрос о языке C, причина, по которой Linux и все системы, соответствующие POSIX или POSIX-ish, должны использовать LF(или, по крайней мере, любой '\n'символ C ), так как символ новой строки является следствием пересечения требований C и POSIX. В то время как C позволяет «текстовым файлам» и «двоичным файлам» различаться (фактически текстовые файлы могут основываться на записях, состоящих из последовательности строчных записей, в дополнение к менее экзотическим вещам, таким как '\n'перевод в / из CR/ LFкак в DOS / Windows ), POSIX требует, чтобы текстовый и двоичный режимы вели себя одинаково. Это в значительной степени причина того, что инструменты командной строки, такие какcatмощны / полезны; их было бы намного меньше, если бы они работали только с двоичным кодом или только с текстом, но не с обоими.

Р..
источник
13
Этот выбор предшествует POSIX на многие годы. Как упоминалось в ответе jlliagre, он восходит к началу Unix, который скопировал его из Multics.
Бармар
4
Выбор в Linux не предшествует POSIX на многие годы. Конечно, POSIX кодифицировал то, что уже было практикой, так как это было причиной его существования.
R ..
Что касается Linux, то в действительности не было никакого реального выбора. Стандартная библиотека Gnu, которая используется в Linux, является современной для POSIX и с самого начала использовала перевод строки по очевидным причинам совместимости, поскольку была разработана, протестирована и использована в системах Unix. Ядро Linux было разработано для обеспечения Unix-подобных системных вызовов стандартной библиотеке C (GNU или другой), и добавление сложности, необходимой для обработки текстовых и бинарных файлов по-разному, было бы излишним и нарушило бы совместимость с существующим кодом. Это было бы бессмысленно от Торвальдса.
jlliagre
@jlliagre: Было все еще выбор сделать что-то совместимое с существующими практиками, а не случайные безвозмездные несовместимости. Вы можете только сказать, что это не был выбор в контексте предположения об успехе Linux. Множество людей делают игрушечные увлеченные ОС предельно дурацкими выборами, и они никуда не денутся.
R ..
@RI означает, что Linux - это всего лишь ядро, и для работы ему по сути требовался GNU (изначально целью Торвальдса была совместимость с minix вместо gnu, но здесь это не имеет значения). Выбор новой строки не связан с Linux, потому что он был сделан задолго до написания Linux. В различных версиях Linux было много более или менее беспричинных дурацких выборов, они не мешали Linux быть успешным. Одна из причин, вероятно, заключается в том, что многие из этих вариантов были пересмотрены позже.
jlliagre