Как поменять в проектах концы строк с CRLF на LF
InterMaster.com.ru
Это может быть интересно не только мне
Как я меняю в проектах концы строк с CRLF на LF
Иногда бывает такая ситуация – получаешь от заказчика движок для его дальнейшего «допиливания». Пытаешься положить его в репозиторий Git – и получаешь кучу варнингов типа:
Это понятно – файлы в исходнике писались/правились до меня разными людьми и на разных операционных системах. Поэтому в файлах наблюдается полная мешанина в вопросе формата окончания строк.
Небольшая справка для тех, кто не в курсе. В разных операционных системах принят разный формат символов, обозначающий перевод строк:
- Windows – rn или CRLF (код 0D0A)
- Unix – n или LF (код 0A)
- Mac – r или CR (код 0D).
Такую разносортицу в своем проекте мне держать не хочется, поэтому я предпочитаю перед началом работ приводить все окончания строк к единому виду – n, он же LF. Почему так? Большинство серверов работают под управлением систем на базе Unix, поэтому, на мой взгляд, логично использовать nix’овые окончания строк и для файлов движка сайта.
Теперь опишу свой способ приведения конца строк к единому виду. Описывать работу буду на примере графической оболочки Git – Git GUI. Так проще и нагляднее.
- Кладу все файлы движка в папку – например, Original.
- Удаляю всякие временные файлы и прочий мусор.
- В пустые папки, которые тем не менее необходимы для работы сайта, кладу файл readme.txt. Это надо по той причине, что Git отслеживает только файлы, а не папки. Поэтому если закоммитить в Git движок с пустыми папками, то потом при выгрузке движка этих пустых, но нужных папок мы не увидим.
- Открываю пункт меню «Редактировать» -> «Настройки» и указываю имя пользователя, email и кодировку файлов проекта.
- В файлах настроек Git – gitconfig – для параметра core прописываю:
- autocrlf = input
- safecrlf = warn
или выполнить команды:
- $ git config –global core.autocrlf input
- $ git config –global core.safecrlf warn
Первый параметр дает команду Git заменить все окончания строк с CRLF в LF при записи в репозиторий.
Второй – выдает предупреждения о конвертации специфических бинарников, если вдруг такие окажутся в движке.
- В результате этой манипуляции у нас на диске C появилась папка Target, в которой лежат файлы из репозитория папки Original. Т.е. в папке Target все концы строк приведены к формату LF или CR.
- Заходим в папку Target, видим в ней папку .git – удаляем эту папку.
- Открываем редактор Notepad++, выбираем пункт меню «Вид» -> «Отображение символов» -> отмечаем «Отображать символ Конец строки». Теперь редактор будет нам показывать символы конца строк.
- Выбираем пункт меню «Поиск» -> «Искать в файлах». В настройках поиска выбираем:
- Режим поиска – Расширенный
- Папка – C:Target
- Найти – r
- В итоге мы найдем все файлы, которые имеют концы строк в формате Mac, т.е.r или CR. Вряд ли их будет много, но иногда встречаются. Открываем каждый файл по очереди в том же редакторе Notepad++. Мы сможем визуально увидеть, что у файла концы строк в формате Mac:
- Преобразуем его в Unix формат. Выбираем «Правка» -> «Формат Конца Строк» -> «Преобразовать в UNIX-формат»
- В итоге файл преобразуется в UNIX-формат.
- Сохраняем файл и выполняем аналогичное преобразование для всех оставшихся файлов в формате Mac. В итоге в папке Target мы будем иметь движок, все файлы которого будут иметь конец строк Unix-формата LF.
Теперь движок можно класть в репозиторий Git. И не забудьте в редакторе, которым выпотом будете править файлы, выставить по умолчанию концовку строк LF, чтобы опять не возникла мешанина.
Git замена LF на CRLF
Запуск git на компьютере под управлением Windows XP с помощью bash. Я экспортировал свой проект из SVN, а затем клонировал голый репозиторий.
Затем я вставлял экспорт в каталог с пустыми репозиториями и делал:
Затем я получил список сообщений:
LF будет заменен на CRLF
Каковы последствия этого преобразования? Это .NET-решение в Visual Studio.
Эти сообщения вызваны неправильным значением по умолчанию core.autocrlf в Windows.
Концепция autocrlf заключается в прозрачной обработке преобразования концов строк. И это делает!
Плохие новости: значение необходимо настроить вручную.
Хорошие новости: это следует делать ОДНО раз за установку git (также возможна настройка каждого проекта).
Как работает autocrlf :
Здесь crlf = маркер конца строки в стиле win, lf = стиль unix (и mac osx).
(pre-osx cr не затронут ни одним из трех вариантов выше)
Когда появляется это предупреждение (под Windows)
– autocrlf = true , если у вас есть lf в стиле Unix в одном из ваших файлов (= В РЕЖИМЕ),
– autocrlf = input , если у вас есть стиль crlf в одном из ваших файлов (= почти ВСЕГДА),
– autocrlf = false – НИКОГДА!
Что означает это предупреждение
Предупреждение “LF будет заменено на CRLF” говорит о том, что вы (имея autocrlf = true ) потеряете свой LF в стиле Unix после цикла фиксации (он будет заменен CRLF в стиле Windows). Git не ожидает, что вы будете использовать LF в стиле Unix под Windows.
Предупреждение “CRLF будет заменен LF” говорит о том, что вы (имея autocrlf = input ) потеряете свой CRLF в стиле Windows после цикла фиксации (он будет заменен LF в стиле Unix). Не используйте input под окнами.
Еще один способ показать, как работает autocrlf
где x – это CRLF (в стиле Windows) или LF (в стиле Unix), а стрелки обозначают
Как исправить
Значение по умолчанию для core.autocrlf выбирается во время установки git и сохраняется в общесистемном gitconfig ( %ProgramFiles(x86)%gitetcgitconfig ). Также есть (каскадирование в следующем порядке):
– “глобальный” (для пользователя) gitconfig, расположенный в
/.gitconfig , еще один
– “глобальный” (для пользователя) gitconfig в $XDG_CONFIG_HOME/git/config или $HOME/.config/git/config и
– “local” (per-repo) gitconfig в .git/config в рабочем каталоге.
Итак, напишите git config core.autocrlf в рабочем каталоге, чтобы проверить текущее используемое значение, и
– добавить autocrlf=false в общесистемное решение gitconfig # для системы
– git config –global core.autocrlf false # решение для каждого пользователя
– git config –local core.autocrlf false # решение для каждого проекта
Предупреждения
– Настройки git config могут быть переопределены настройками gitattributes .
– Преобразование crlf -> lf происходит только при добавлении новых файлов, на файлы crlf , уже существующие в репо, это не влияет.
Мораль (для Windows):
– используйте core.autocrlf = true , если вы планируете использовать этот проект также под Unix (и не хотите настраивать ваш редактор /IDE для использования концов строк Unix),
– используйте core.autocrlf = false , если вы планируете использовать этот проект только под Windows (или вы настроили свой редактор /IDE для использования концов строк Unix),
– никогда не используйте core.autocrlf = input , если у вас нет веских причин (например, если вы используете утилиты Unix под Windows или если у вас возникают проблемы с makefiles),
PS Что выбрать при установке git для Windows?
Если вы не собираетесь использовать какой-либо из ваших проектов под Unix, не соглашайтесь с первым вариантом по умолчанию. Выберите третий (Оформить как есть, зафиксировать как есть). Вы не увидите это сообщение. Когда-либо.
git замена LF на CRLF
Запуск git на машине Windows XP с использованием bash. Я экспортировал свой проект из SVN, а затем клонировал голый репозиторий.
Затем я вставил экспорт в каталог голых хранилищах, и сделал:
Затем я получил список сообщений со словами:
LF будет заменен на CRLF
Каковы последствия этого обращения? Это решение .NET в Visual Studio.
19 Ответов
Эти сообщения вызваны неправильным значением по умолчанию core.autocrlf на Windows.
Концепция autocrlf заключается в том, чтобы прозрачно обрабатывать преобразования окончаний строк. И это действительно так!
Плохая новость: значение должно быть настроено вручную.
Хорошая новость: это должно быть сделано только ONE раз за установку git (также возможна настройка проекта).
Как работает autocrlf :
Здесь crlf = win-style end-of-line маркер, lf = unix-style (и mac osx).
(предварительно на OSX cr не влияет на любой из трех вышеперечисленных вариантов )
Когда появляется это предупреждение (под Windows)
– autocrlf = true если у вас есть unix-style lf в одном из ваших файлов (= RARELY),
– autocrlf = input если у вас есть win-style crlf в одном из ваших файлов (= почти ALWAYS),
– autocrlf = false – NEVER!
Что означает это предупреждение
Предупреждение “LF будет заменено на CRLF” говорит о том, что вы (имея autocrlf = true ) потеряете свой unix-стиль LF после цикла фиксации-проверки (он будет заменен на windows-стиль CRLF). Git не ожидает, что вы будете использовать unix-style LF под windows.
Предупреждение “CRLF будет заменено на LF” говорит о том, что вы (имея autocrlf = input ) потеряете свой windows-стиль CRLF после цикла фиксации-проверки (он будет заменен на unix-стиль LF). Не используйте input под windows.
Еще один способ показать, как работает autocrlf
где x – либо CRLF (windows-стиль), либо LF (unix-стиль), а стрелки обозначают
Как это исправить
Значение по умолчанию для core.autocrlf выбирается во время установки git и сохраняется в общесистемном gitconfig ( %ProgramFiles(x86)%gitetcgitconfig ). Также есть (каскадирование в следующем порядке):
– “global” (для каждого пользователя) gitconfig расположен на
/.gitconfig , еще один
– “global” (для каждого пользователя) gitconfig на уровне $XDG_CONFIG_HOME/git/config или $HOME/.config/git/config и
– “local” (per-repo) gitconfig at .git/config в рабочем реж.
Итак, напишите git config core.autocrlf в рабочем dir, чтобы проверить текущее используемое значение и
-добавить autocrlf=false в общесистемный gitconfig # для каждого системного решения
– git config –global core.autocrlf false # решение для каждого пользователя
– git config –local core.autocrlf false # решение для каждого проекта
Предупреждение
– Настройки git config могут быть переопределены настройками gitattributes .
– Преобразование crlf -> lf происходит только при добавлении новых файлов, crlf файлы, уже существующие в РЕПО, не затрагиваются.
Мораль (для Windows):
– используйте core.autocrlf = true , если вы также планируете использовать этот проект под Unix (и не хотите настраивать редактор/IDE на использование окончаний строк unix),
– используйте core.autocrlf = false , если вы планируете использовать этот проект только под Windows (или вы настроили редактор/IDE для использования окончаний строк Windows),
– никогда не используйте core.autocrlf = input , если у вас нет веской причины ( например , если вы используете утилиты unix под windows или если вы столкнулись с проблемами makefiles),
PS что выбрать при установке git для Windows?
Если вы не собираетесь использовать ни один из ваших проектов под Unix, не соглашайтесь с первым вариантом по умолчанию. Выберите третий вариант (Checkout as-is, commit as-is ). Вы не увидите этого сообщения. Когда-либо.
PPS мои личные предпочтения-это настройка редактора/IDE для использования окончаний в стиле Unix и установка core.autocrlf на false .
Git имеет три режима обработки окончаний строк:
Вы можете установить режим для использования, добавив дополнительный параметр true или false в приведенную выше командную строку.
Если core.autocrlf имеет значение true, это означает, что каждый раз, когда вы добавляете файл в репо git, который git считает текстовым файлом, он превратит все окончания строки CRLF в просто LF, прежде чем сохранить его в фиксации. Всякий раз, когда вы что-то git checkout , все текстовые файлы автоматически будут иметь свои LF окончаний строк, преобразованных в CRLF окончаний. Это позволяет разрабатывать проект на разных платформах, которые используют разные стили окончания строк, не делая фиксации очень шумными, потому что каждый редактор изменяет стиль окончания строки, поскольку стиль окончания строки всегда последовательно LF.
Побочный эффект этого удобного преобразования, и это то, о чем вы видите предупреждение, заключается в том, что если текстовый файл, который вы создали, изначально имел LF окончание вместо CRLF, он будет сохранен с LF, как обычно, но при последующем извлечении он будет иметь CRLF окончания. Для обычных текстовых файлов это обычно просто прекрасно. В этом случае предупреждение является “for your information”, но в случае, если git неверно оценивает двоичный файл как текстовый, это важное предупреждение, потому что git тогда будет разрушать ваш двоичный файл.
Если параметр core.autocrlf имеет значение false, то преобразование конца строки никогда не выполняется, поэтому текстовые файлы проверяются в параметре as-is. Обычно это работает нормально, пока все ваши разработчики находятся либо на Linux, либо все на Windows. Но по своему опыту я все еще склонен получать текстовые файлы со смешанными окончаниями строк, которые в конечном итоге вызывают проблемы.
Мое личное предпочтение состоит в том, чтобы оставить настройку включенной ON, как разработчик Windows.
См. http://kernel.org/pub/software/scm/git/docs/git-config.html для получения обновленной информации, включающей значение “input”.
Если вы уже проверили код, то файлы уже проиндексированы. После изменения настроек git вы должны обновить индексы с помощью
Git заменяет LF на CRLF
Запуск git на компьютере под управлением Windows XP с помощью bash. Я экспортировал свой проект из SVN, а затем клонировал голый репозиторий.
Затем я вставлял экспорт в каталог с пустыми репозиториями и делал:
Затем я получил список сообщений:
LF будет заменен на CRLF
Каковы последствия этого преобразования? Это .NET-решение в Visual Studio.
19 ответов
Git имеет три режима обработки строк:
Вы можете установить режим использования, добавив дополнительный параметр true или false в приведенную выше командную строку.
Если для параметра core.autocrlf установлено значение true, это означает, что каждый раз, когда вы добавляете файл в репозиторий git, который git считает текстовым файлом, он завершает окончание строк CRLF только LF до того, как он сохранит это в фиксации. Всякий раз, когда вы git checkout что-то, все текстовые файлы автоматически будут иметь окончание строк LF, преобразованное в окончания CRLF. Это позволяет разрабатывать проект на разных платформах, которые используют разные стили, отличные от строк, без коммиттов, которые очень шумны, потому что каждый редактор меняет стиль окончания строки, так как стиль окончания строки всегда всегда LF.
Побочный эффект этого удобного преобразования, и это то, о чем предупреждает вас, заключается в том, что если текстовый файл, который вы создали, первоначально имел LF-окончания вместо CRLF, он будет храниться с LF, как обычно, но после этого он будет иметь окончания CRLF. Для обычных текстовых файлов это нормально. Предупреждение является “для вашей информации” в этом случае, но в случае, если git неправильно оценивает двоичный файл как текстовый файл, это важное предупреждение, потому что git будет искажать ваш двоичный файл.
Если для параметра core.autocrlf установлено значение false, преобразование окончания строки никогда не выполняется, поэтому текстовые файлы проверяются как-есть. Это обычно работает нормально, если все ваши разработчики либо находятся в Linux, либо все в Windows. Но, по моему опыту, я все еще стараюсь получать текстовые файлы со смешанными окончаниями строк, которые в конечном итоге вызывают проблемы.
Мое личное предпочтение – оставить настройку включенной, как разработчик Windows.
Эти сообщения из-за неправильного значения по умолчанию core.autocrlf в Windows.
Концепция autocrlf заключается в прозрачной обработке преобразования autocrlf строк. И это делает!
Плохая новость: значение необходимо настроить вручную.
Хорошая новость: делать это нужно ОДНО раз за установку git (также возможна настройка каждого проекта).
Как работает autocrlf :
Здесь crlf = маркер конца строки в стиле win, lf = стиль unix (и mac osx).
(pre-osx cr не затронут ни для одного из трех вариантов выше)
Когда появляется это предупреждение (под Windows)
– autocrlf = true если в одном из ваших файлов есть lf в стиле Unix (= RARELY),
– autocrlf = input если в одном из ваших файлов есть crlf в стиле crlf (= почти ВСЕГДА),
– autocrlf = false – НИКОГДА!
Что означает это предупреждение
Предупреждение “LF будет заменено на CRLF” говорит о том, что вы (имея autocrlf = true ) потеряете свой LF в стиле Unix после цикла подтверждения (он будет заменен на CRLF в стиле Windows). Git не ожидает, что вы будете использовать LF в стиле Unix под Windows.
Предупреждение “CRLF будет заменен на LF” говорит о том, что вы (с autocrlf = input ) потеряете свой CRLF в стиле Windows после цикла подтверждения (он будет заменен LF в стиле Unix). Не используйте input под окнами.
Еще один способ показать, как работает autocrlf
где x – это CRLF (в стиле Windows) или LF (в стиле Unix), а стрелки обозначают
Как исправить
Значение по умолчанию для core.autocrlf выбирается во время установки git и сохраняется в общесистемном gitconfig ( %ProgramFiles(x86)%gitetcgitconfig ). Также есть (каскадирование в следующем порядке):
– “глобальный” (для пользователя) gitconfig, расположенный в
/.gitconfig , еще один
– “глобальный” (для пользователя) gitconfig в $XDG_CONFIG_HOME/git/config или $HOME/.config/git/config и
– “local” (per-repo) gitconfig в .git/config в рабочем каталоге.
Итак, напишите git config core.autocrlf в рабочем git config core.autocrlf чтобы проверить текущее используемое значение и
– добавить autocrlf=false в общесистемное решение gitconfig # для системы
– git config –global core.autocrlf false # решение для каждого пользователя
– git config –local core.autocrlf false # решение для каждого проекта
Предупреждения
– настройки git config могут быть переопределены настройками gitattributes .
– crlf → lf преобразование происходит только при добавлении новых файлов, на файлы crlf уже существующие в репо, это не влияет.
Мораль (для Windows):
– используйте core.autocrlf = true если вы планируете использовать этот проект также и под Unix (и не хотите настраивать ваш редактор /IDE для использования концов строк Unix),
– используйте core.autocrlf = false если вы планируете использовать этот проект только под Windows (или вы настроили свой редактор /IDE для использования концов строк Windows),
– никогда не используйте core.autocrlf = input если у вас нет веских причин (например, если вы используете утилиты unix под windows или если у вас возникают проблемы с makefiles),
PS Что выбрать при установке git для Windows?
Если вы не собираетесь использовать какой-либо из ваших проектов под Unix, не соглашайтесь с первым вариантом по умолчанию. Выберите третий (Оформить заказ как есть, зафиксировать как есть). Вы не увидите это сообщение. Когда-либо.
qpi2
Ruby. Исповедь самоучки
журнал для начинающих рубистов
Строки. Методы работы со строками. Часть II
Первая часть темы работы со строками находится здесь.
2.20 String#chop, String#chop!
Методы обрезают последний символ строки кроме случая когда последними двумя символами является rn(виндовый переход на новую строку), тогда обрезаются оба символа.
BANG метод #chomp! преобразует объект или возвращает nil , а #chomp возвращает новую строку.
Метод #chr возвращает первый символ (символьный тип character) строки.
Метод #clear очищает строку. Он ведет себя как BANG метод, хотя отличительный знак (!) у него не стоит. Нз почему так. Возможно ситуация прояснится в комментариях к статье.
Возвращает массив порядковых чисел множества символов character. Является сокращенной записью выражения str.each_codepoints.to_a . Если методу #codepoints передан блок кода, то ведет себя также как и each_codepoints
Каждый параметр other_str преобразуется в множество символов character. Метод подсчитывает количество символов str, которые принадлежат этому множеству. При помощи символа “галочка” (^) задаются исключения из множества. Выражения типа c1-c2 задают множество символов, которые располагаются между символами c1 и c2.
Применяет однопроходное криптографическое хеширование к строке str посредством функции crypt из стандартной библиотеки языка Си. Аргументом метода является строка salt_str, которая содержит “соль” для хеширования. Соль должна соответствовать регулярному выражению A[a-zA-Z0-9./]<2>.
Пользоваться этим методом не рекомендовано из-за его простоты.
Метод возвращает копию строки str в которой удалены все символы переданные в other_str. Поиск символов для удаления происходит также как их подсчитывает метод #count (п. 2.23)
Все 4 метода управляют регистром символов.
#downcase и #downcase! – нижний регистр, #upcase и #upcase! – верхний регистр.
Важно. Действие методов распространяется только на латинские символы.
Создает версию строки str в которой все непечатные символы заменены на nnn нотацию и все специальные символы (escape последовательности) экранированы.
Метод в цикле пробегает по каждому байту строки в заданном блоке кода. В случае если блок кода не задан, возвращается экземпляр класса Enumerator
В случае если методу передан блок кода, то в блок передается каждый символ строки. Если же блок не задан – возвращает экземпляр класса Enumerator
В случае если методу передан блок кода, то в блок передается порядковое число (цифровая ссылка) каждого символа строки. Если же блок не задан – возвращает экземпляр класса Enumerator
Метод #each_line разбивает строку str используя значение параметра separator, и передает каждую из подстроку в блок. Если в качестве параметра separator передается пустая строка, то строка будет делится по символу n (разрыв строки), исключая случай, когда несколько символов n идут подряд (все символы n будут засчитываться как один).
Метод возвращает true если длина строки равна нулю, иначе – false
Как конвертировать CRLF в LF на машине Windows в Python
Итак, я получил этот шаблон, все они заканчиваются в LF, и я могу заполнить некоторые термины внутри с форматом и все равно получить LF файлы, открыв с помощью «wb»
Эти шаблоны используются в развертывании script на машине Windows для развертывания на сервере unix.
Проблема в том, что многие люди собираются возиться с этим шаблоном, и я на 100% уверен, что некоторые из них будут помещать некоторые CRLF внутрь.
Как я мог, используя python преобразовать все crlf в lf?
ИЗМЕНИТЬ
Ну, я плохо, у меня была ошибка в моем коде, открытие в «wb» всегда помещало lf в конец строк, даже если файл использовал crlf раньше.
Вот код, который я использую, если вам интересно:
Так что проблем нет, все работает нормально: x
Открытая функция Python поддерживает режим ‘rU’ для универсальных строк новой строки, и в этом случае он не против, какой тип новой строки имеет каждая строка. В Python 3 вы также можете запросить конкретную форму новой строки с аргументом newline для open.
Таким образом, переход от одной формы к другой довольно простой в Python:
(Из-за аргумента новой строки U фактически не рекомендуется в Python 3, эквивалентная форма — newline=None .)
Преобразование окончаний строк на месте (с помощью Python 3)
Windows для Linux/Unix
Ниже приведен короткий скрипт для прямого преобразования окончаний строк Windows ( rn также называемого CRLF ) в конец строки Linux/Unix ( n также называемый LF ) на месте (без создания дополнительного выходного файла):
Linux/Unix для Windows
Просто поменяйте окончание строки на content.replace(UNIX_LINE_ENDING, WINDOWS_LINE_ENDING) .
Обозначение кода
Важно: двоичный режим. Нам нужно убедиться, что мы открываем файл оба раза в двоичном режиме ( mode=’rb’ и mode=’wb’ ) для преобразования в работу.
При открытии файлов в текстовом режиме ( mode=’r’ или mode=’w’ без b ) окончание собственных строк платформы ( rn в Windows и r на старых версиях Mac OS) автоматически преобразуется в Python Unix- конец строки строки: n . Поэтому вызов content.replace() не смог найти никаких окончаний строк для замены.
В двоичном режиме такое преобразование не выполняется.
Двоичные строки В Python 3, если не указано иначе, строки сохраняются как Unicode ( UTF-8 ). Но мы открываем наши файлы в двоичном режиме — поэтому нам нужно добавить b перед нашими заменяющими строками, чтобы сказать Python также обрабатывать эти строки как двоичные.
Необработанные строки В Windows разделитель путей — это обратная косая черта которую нам нужно будет сбежать в обычной строке Python с \ . Добавляя r перед строкой, мы создаем так называемую необработанную строку, которая не нуждается в экранировании. Таким образом, вы можете напрямую скопировать/вставить путь из проводника Windows.
Альтернатива Мы открываем файл дважды, чтобы избежать необходимости перестановки указателя файла. Мы также могли бы открыть файл один раз с помощью mode=’rb+’ но тогда нам нужно было бы переместить указатель назад, чтобы начать его чтение ( open_file.seek(0) ), и open_file.seek(0) его исходное содержимое перед написанием нового one ( open_file.truncate(0) ).
Простое открытие файла в режиме записи делает это автоматически для нас.
Приветствия и счастливое программирование,
winklerrr
Можно исправить существующие шаблоны с испорченным окончанием с помощью этого кода:
