Я хочу изменить EOL по умолчанию моей системы Linux с \n на \r\n без перекомпиляции. Какая-либо конфигурация делает это возможным (возможно, локаль)?
Причина: Я должен убедиться, что для каждого пользователя, создающего файл, файл будет правильно отформатирован (без необходимости использовать unix2dos или что-то еще)
решение1
Я редактирую свой ответ, чтобы предоставить это резюме сверху. Я считаю, что прямой ответ на ваш основной вопрос: "Нет, это не опция, которая обычно поддерживается во многих системах Linux". Ниже приведено мое более подробное объяснение.
Я сомневаюсь, что это можно легко сделать. В теории, несколько операционных систем используют разные символы новой строки, как заметилВикипедия: Представления. Теоретически программисты не должны ссылаться на \n или \r\n, когда они хотят представить «символ новой строки» (который может быть символом, например, символом разделителя записей старых систем QNX или \r\n, например, MS-DOS). Таким образом, если кто-то (вскоре или в будущем) захочет повторно использовать код, он может просто изменить одну переменную.
На практике многие программисты известны тем, что «жестко кодируют» значения. Вы можете использовать «Linux from Scratch» и настраивать систему так, как вам нравится. Я полагаю, что если вы измените исходный код, вы сможете сделать так, чтобы все файлы конфигурации вашей системы использовали любую предпочтительную последовательность новой строки.
Однако что происходит позже, когда пользователь хочет использовать определенный текстовый редактор или определенный веб-браузер? Готовы ли вы пойти и «исправить» свою собственную вариацию исходного кода веб-браузера Google Chromium, просто чтобы приспособиться к этому изменению?
Как вы можете видеть изКомментарий КрисаЭдмонтона, реализация этого изменения на самом деле была бы необычной. Это означает, что вы, скорее всего, обнаружите, что многие вещи не работают хорошо с целью одного человека реализовать такую гибкость. Так что вы, скорее всего, столкнетесь с довольно большим количеством проблем. Я предполагаю, что вы, скорее всего, столкнетесь с довольно большим количеством проблем в будущем, после того, как все изначально казалось в порядке.
Лично для меня мои компьютерные данные имеют некоторую ценность. Даже данные, которые настолько бесполезны, что я не беспокоюсь о том, чтобы их резервировать, имеют для меня достаточную ценность, чтобы я не хотел намеренно делать что-то, что может вызвать проблемы. (То, что я готов позволить данным быть потерянными в маловероятном случае катастрофы, не означает, что я хочу метафорически вылить бензин на пол с одной стороны дома, бесполезно намеренно создавая ситуацию, которая может вызвать катастрофу.)
Так что если вы не готовы рассматривать все виды вещей, включая драйверы файловой системы и код ядра, который обрабатывает память, и все другие аспекты системы, то это, вероятно, не стоит того, чтобы заниматься этим. Я предлагаю использовать другой способ реализации изменения.
Да, я знаю аргумент, что Linux должен быть открытым исходным кодом, поэтому он должен быть настраиваемым. Но реальность такова, что Linux так вырос, что внесение изменений может иметь значительные последствия. Имейте в виду, что существуют различные версии Linux (Debian, Ubuntu, Mint, Red Hat, SUSE и т. д.), не говоря уже о других Unix-подобных операционных системах (BSD, Solaris, Mac OS X) и других операционных системах (Windows, DOS, CPM, VMS). Теоретически внесение таких изменений должно быть проще, чем попытка убедить Microsoft внести изменения в их закрытую операционную систему. На практике может быть много людей, которых вам нужно будет убедить, чтобы внести изменения в некоторые из наиболее популярных программ. Внесение изменений может сломать все, поэтому изменения следует вносить, когда есть существенная, существенная выгода. Более легкомысленные изменения вряд ли будут стоить тех трудностей, которые они могут реализовать.
Некоторые люди хотели бы, чтобы такие изменения были легко модифицируемой опцией. Одна из проблем с большим количеством опций заключается в том, что слишком много опций могут загромождать пользовательские интерфейсы, загромождать документацию и усложнять исходный код (даже если добавленная сложность довольно мала), поэтому есть люди, которые продвигают идею создания стандартов и сокращения опций ради простоты. Поэтому изменение типа «настроить символ новой строки для программного обеспечения, которое поддерживает эту опцию» может принести больше боли, чем ожидаемой выгоды от такой опции.
Приведенная вами причина заключается в том, что вы не хотите, чтобы пользователь использовал "unix2dos" при создании файла. Как пользователь создает файл? Запускает ли пользователь "nano"? Вы могли бы потенциально заменить "nano" скриптом, который запускает обычный nano, а затем автоматически запускает unix2dos. Вы могли бы изменить процесс, которым пользователи создают/редактируют файлы, или вы могли бы изменить процесс, который влияет на то, как файл передается на другие машины, которые могут ожидать \r\n (и затем не заботиться о том, использует ли файл только \n, пока файл все еще находится на машине Linux). Такие целевые подходы с большей вероятностью сработают без непреднамеренных последствий, чем попытка внести общесистемные изменения, которые повлияют на работу всей системы.