Я хочу изменить стандартное EOL моей системы Linux с \n на \r \n без перекомпиляции. Любая конфигурация делает это возможным (возможно, локаль)?
Причина: я должен убедиться, что для каждого пользователя, который создает файл, файл будет правильно отформатирован (не заставляя его использовать unix2dos или что-то еще)
Я редактирую свой ответ, чтобы обеспечить это резюме сверху. Я полагаю, что прямой ответ на ваш базовый вопрос: «Нет, этот вариант обычно не поддерживается во многих системах Linux». Ниже приведено мое более подробное объяснение.
Я сомневаюсь, что это может быть легко сделано. Теоретически, несколько операционных систем используют разные символы новой строки, как отмечено в Wikipedia: Представления. Теоретически, программисты не должны ссылаться на \n или \r \n, когда они хотят представить «символ новой строки» (который может быть символом, таким как символ Разделитель записей в старых системах QNX, или \r \n, как MS -DOS). Таким образом, если кто-то (скоро или в будущем) захочет повторно использовать код, он может просто изменить одну переменную.
На практике многим программистам известны значения «жесткого кода». Вы можете использовать «Linux с нуля» и настраивать систему так, как вам нравится. Я полагаю, что если вы изменили исходный код, вы могли бы сделать так, чтобы все файлы конфигурации вашей системы использовали любую последовательность новой строки, которую вы предпочитаете.
Однако что произойдет позже, когда пользователь захочет использовать определенный текстовый редактор или определенный веб-браузер? Готовы ли вы «исправить» свой собственный вариант исходного кода браузера Google Chromium, просто чтобы учесть это изменение?
Как вы можете видеть из комментария ChrisEdmonton, реализация этого изменения на самом деле была бы необычной. Это означает, что вы, вероятно, обнаружите, что многие вещи плохо работают с целью реализации такой гибкости одним человеком. Таким образом, вы, вероятно, столкнетесь с довольно многими проблемами. Я предполагаю, что вы, вероятно, столкнетесь с довольно большим количеством проблем в будущем, ну, после того, как все поначалу будет хорошо
Лично мои компьютерные данные имеют для меня какое-то значение. Даже данные, которые настолько бесполезны, что я не потрудился их подкрепить, имеют для меня достаточную ценность, поэтому я не хочу намеренно делать что-то, что может вызвать проблемы. (То, что я хочу позволить потерять данные в маловероятном случае катастрофы, не означает, что я хочу метафорически выбрасывать бензин по всему полу с одной стороны дома, бесполезно преднамеренно создавая ситуацию, которая может привести к катастрофе.)
Так что, если вы не желаете рассматривать все виды вещей, включая драйверы файловой системы и код ядра, который обрабатывает память, и все другие аспекты системы, то, вероятно, это не стоит того, чтобы заниматься этим. Я предлагаю использовать другой способ реализации изменений.
Да, я знаю аргумент, что 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). Такие целевые подходы, скорее всего, сработают без непредвиденных последствий, вместо того, чтобы пытаться внести изменения в масштабе всей системы, которые влияют на работу всей системы.
