Unix lf как преобразовать windows cr lf

Иногда бывает такая ситуация – получаешь от заказчика движок для его дальнейшего «допиливания». Пытаешься положить его в репозиторий Git – и получаешь кучу варнингов типа:

LF will be replaced by CRLF in index.php

Это понятно — файлы в исходнике писались/правились до меня разными людьми и на разных операционных системах. Поэтому в файлах наблюдается полная мешанина в вопросе формата окончания строк.

Небольшая справка для тех, кто не в курсе. В разных операционных системах принят разный формат символов, обозначающий перевод строк:

• Windows — rn или CRLF (код 0D0A)
• Unix — n или LF (код 0A)
• Mac — r или CR (код 0D).

Такую разносортицу в своем проекте мне держать не хочется, поэтому я предпочитаю перед началом работ приводить все окончания строк к единому виду — n, он же LF. Почему так? Большинство серверов работают под управлением систем на базе Unix, поэтому, на мой взгляд, логично использовать nix’овые окончания строк и для файлов движка сайта.

Теперь опишу свой способ приведения конца строк к единому виду. Описывать работу буду на примере графической оболочки Git – Git GUI. Так проще и нагляднее.

1. Кладу все файлы движка в папку – например, Original.
2. Удаляю всякие временные файлы и прочий мусор.
3. В пустые папки, которые тем не менее необходимы для работы сайта, кладу файл readme.txt. Это надо по той причине, что Git отслеживает только файлы, а не папки. Поэтому если закоммитить в Git движок с пустыми папками, то потом при выгрузке движка этих пустых, но нужных папок мы не увидим.
4. Открываю пункт меню «Редактировать» -> «Настройки» и указываю имя пользователя, email и кодировку файлов проекта.
5. В файлах настроек Git – gitconfig — для параметра core прописываю:
• autocrlf = input
• safecrlf = warn

или выполнить команды:

• $ git config —global core.autocrlf input
• $ git config —global core.safecrlf warn

Первый параметр дает команду Git заменить все окончания строк с CRLF в LF при записи в репозиторий.

Второй – выдает предупреждения о конвертации специфических бинарников, если вдруг такие окажутся в движке.

6. Теперь записываю все файлы движка в репозиторий. В итоге в репозитории все файлы будут иметь концы строк LF или CR (т.к. Git сконвертировал только CRLF в LF, преобразование CR->LF от не выполняет).
7. Запускаю Git GUI, выбираю «Склонировать существующий репозиторий».
8. В строке «Исходное положение» указываю папку Original.
9. В строке «Каталог назначения» указываю полный пусть к папке, в которую я хочу скопировать репозиторий из папки Original. В данном случае я указал папку Target. Важно: папки с таким именем на диске быть не должно. Git GUI создаст ее сам.
10. Выбираю «Полная копия».
11. Жму «Склонировать».

1. В результате этой манипуляции у нас на диске C появилась папка Target, в которой лежат файлы из репозитория папки Original. Т.е. в папке Target все концы строк приведены к формату LF или CR.
2. Заходим в папку Target, видим в ней папку .git – удаляем эту папку.

1. Открываем редактор Notepad++, выбираем пункт меню «Вид» -> «Отображение символов» -> отмечаем «Отображать символ Конец строки». Теперь редактор будет нам показывать символы конца строк.

1. Выбираем пункт меню «Поиск» -> «Искать в файлах». В настройках поиска выбираем:
• Режим поиска – Расширенный
• Папка – C:Target
• Найти — r

Жмем «Найти все»

1. В итоге мы найдем все файлы, которые имеют концы строк в формате Mac, т.е.r или CR. Вряд ли их будет много, но иногда встречаются. Открываем каждый файл по очереди в том же редакторе Notepad++. Мы сможем визуально увидеть, что у файла концы строк в формате Mac:

1. Преобразуем его в Unix формат. Выбираем «Правка» -> «Формат Конца Строк» -> «Преобразовать в UNIX-формат»

1. В итоге файл преобразуется в UNIX-формат.

1. Сохраняем файл и выполняем аналогичное преобразование для всех оставшихся файлов в формате Mac. В итоге в папке Target мы будем иметь движок, все файлы которого будут иметь конец строк Unix-формата LF.

Теперь движок можно класть в репозиторий Git. И не забудьте в редакторе, которым выпотом будете править файлы, выставить по умолчанию концовку строк LF, чтобы опять не возникла мешанина.

I’m going to throw this solution out there. Git will do this. See this post about it

So theoretically you could do this to convert an entire tree

cd root/of/tree
git init .
git add .
git commit -m "initial commit"
echo "* text eol=crlf" > .gitattributes
git rm --cached -r .
git reset --hard

Change crlf to lf if you want to go the other way. NOTE: you’re not done yet, keep reading

Type git status to see which files will be affected. You might have to add lines like

*.jpg binary
*.png binary
*.gif binary

etc to .gitattributes to avoid converting certain files. You can also explicit mark certain files as text

*.md text
*.css text

Then just repeat these 2 lines after you’ve edited .gitattributes

git rm --cached -r .
git reset --hard

Then use git status again to see which files will be changed. When you’re sure all the files you want affected are listed by git status then commit

git add .
git commit -m "normalize line endings"

now check all the files out again

git rm --cached -r .
git reset --hard

They should now have whatever your desired line endings are

** NOTE: If you were already using git skip the first 3 commands git commands. If you were not using git you can now delete the .gitattributes file and the .git folder.

** Back up your files: the git rm --cached -r deletes them all (although they are theoretically in your git repo (the .git folder) which is how they get restored by the last command git reset --hard. It’s just since files are getting deleted it’s probably best to back them up.

Question

How to convert a UNIX  LF to a CR/LF? (SCI57956)

Answer

Connect:Direct alone does not do this.  Please use other utilities to accomplish this.  See examples below:

1) Use a freeware utility or create a simple script which uses cat and/or  sed to add the CR to the LF:  Example follows showing how to accomplish the same funtcions using a script which contains cat and sed:  
Write dos2unix and unix2dos as scripts, see examples below:
The equivalent scripts look like:
 ====== dos2unix ======
cat file | sed «s/^M{1,}$//» | sed «$ s/^Z//» > file.new
====== unix2dos ======
cat file | sed «s/$/^M/» | sed «$ s/$/^Z/» > file.new

2) On Windows or UNIX, gzip and gunzip has a -a switch that tells Windows gunzip to uncompress a file and change all LF’s to CRLF.

3) If this is a PGP file, UNIX and Linux has several different utilities that change «UNIX» text files to «Windows» text files.  One of these utilities can be run by inserting into a exiisting or new C:Direct UNIX process, an extra runtask step ( or extending a current runtask and pipe «|» the output straight into the PGP command they’re already running on the box). Probably the fastest is the stream editor, «sed».

Assuming Step01 is the mainframe to Linux transfer, then step02 could be something like

Step02 (if step01 <=4 then)</font></font></p>

runtask (sed command to convert LF to CRLF)

Step03 (if step02 = 0 then)

runtask (PGP-encrypt the new file as before)

Step04 (if step03 = 0 then)

continue processing as before. Send file on to next UNIX machine.

In this scenario the customer would not have change anything. This will add a very small resource impact to that Linux box.

Here are some sed examples to use under Linux. At the end, the output is piped straight into another text file. However, the output could also be piped straight into the current PGP runtask with the «|» symbol.

# command line under ksh

cat mainframe.txt | sed «s/$/`echo -e \r`/» > windows.txt

# command line under bash

cat mainframe.txt | sed ‘s/$'»/`echo \r`/» > windows.txt

Один из самых частых вопросов о Гите — почему так сложно работать с окончаниями строк. В этой статье мы попробуем ответить на этот вопрос и рассказать о множестве опций и настроек для контроля над окончаниями строк в Гите.

Гит имеет дело с двумя системами для работы с концами строк в репозиториях. Корень проблемы в том, что популярные операционные системы по-разному обозначают конец строки: Unix, Linux и Mac OS X используют LF, а Windows CRLF.
В этой статье мы не будем брать во внимание, что в предыдущих версиях Mac OS X использовался CR.

Ничего из этого не было бы проблемой, если бы каждый из нас жил в своём маленьком, изолированном мире и никогда не обменивался кодом между разными операционными системами. Под обменом кодом, в данном случае, будем понимать всё — от работы над кросс-платформенным проектом до копирования кода из браузера. Всякий раз, когда вы скачиваете архив проекта с Гитхаба, копируете код из чьего-то блога или гиста или используете код из файла на облачном хранилище, вы работаете с текстом, а значит имеете дело с невидимыми символами окончаний строк.

Все эти действия с кодом потенциально могут привнести разные настройки окончаний строк в вашу кодовую базу. Это может привести к беспорядочным диффам и сделать работу с Гитом в целом неприятной.

Основное решение, которое принял Гит для этой проблемы — указать, что лучший способ хранить окончания строк в репозитории для текстовых файлов — использование LF. Это правило ни к чему вас не принуждает, но большинство разработчиков, использующих Гит и Гитхаб, приняли его как соглашение и мы тоже рекомендуем так настроить ваш конфиг.

Основы

Перед тем, как мы опишем настройки для управления окончаниями строк, нам надо узнать несколько вещей о core.eol и разобраться с тем, что значит записать что-либо в базу данных Гит.

Конец строки

core.eol — первый параметр, о котором нужно знать.

Почти всегда, кроме самых редких случаев, нам не стоит менять дефолтное значение этого параметра. Хотя сам по себе core.eol мало что делает, нам нужно знать его значение каждый раз, когда мы хотим, чтобы Гит изменил окончания строк. Так как этот параметр будет использоваться во всём, о чём пойдёт речь дальше, хорошо бы знать о его существовании и о том, что его значение, вероятно, менять не придётся.

• core.eol = native — значение по умолчанию. При записи файла в рабочую папку, Гит изменит окончания строк на соответствующие вашей платформе по умолчанию. Для Windows это будет CRLF, для Unix, Linux и Mac OS X — LF;
• core.eol = crlf— если установлено такое значение, Гит всегда будет использовать для обозначения конца строки CRLF при записи файла в вашу рабочую директорию;
• core.eol = lf — это значение скажет Гиту всегда использовать LF для обозначения конца строки при записи файла в вашу рабочую папку.

Чтобы узнать, какое значение core.eol установлено в вашей системе, нужно запустить в консоли команду git config --global core.eol. Если команда ничего не вернёт, значит, в вашей системе используется значение по умолчанию, native.

Запись и вывод объектов из базы данных

Прежде чем двигаться дальше, мы поговорим о двух важных операциях: записи в объектную базу и выводе данных из неё в рабочую директорию.
Возможно, вы уже знаете, что Гит хранит свою базу данных в папке .git. Он создаёт эту директорию и несколько файлов в ней, после запуска команды git init. Файлы в папке .git определяют все конфигурации Гита, в них хранится история проекта. Это обычные файлы и мы можем их читать и редактировать так же, как файлы самого проекта.

Каждый раз, когда мы делаем команду типа git commit, мы записываем объекты в эту базу данных. Запись в базу данных включает в себя:

• сохранение всего содержимого файла;
• добавление его в список со всеми файлами, которые отслеживает Гит;
• создание блоб-файла;
• вычисление SHA-ключа — хэш-кода, в котором хранится информация о содержимом файла.

Во время записи в базу данных **Гит может запустить фильтры и преобразовать окончания строк.

Есть ещё один случай, когда у Гита появляется возможность преобразовать окончания строк — это запись файлов из базы данных в нашу рабочую папку. Это то, что мы подразумеваем под выводом из базы данных. Такой процесс можно запустить множеством команд, но самая очевидная и простая для понимания — git checkout. Вывод из объектной базы данных также происходит после запуска команд, которые делают изменения в нашей рабочей папке, например, git clone или git reset.

Старая система

Теперь давайте поговорим о старой системе — оригинальном наборе функций в Гите, предназначенном для решения конкретной проблемы с окончаниями строк. Есть большая вероятность, что вы прямо сейчас пользуетесь старой системой и даже не подозреваете об этом.

Вот как это работает: у Гита есть настройка конфигураций core.autocrlf, которая специально создана для того, чтобы все окончания строк в текстовом файле преобразовывались в LF при записи в объектную базу данных репозитория. Вот список разных настроек для core.autocrlf и их значений:

• core.autocrlf = false — это значение по умолчанию, которое большинству людей следует сменить. Результатом использования этого значения станет то, что Гит не будет связываться с окончаниями строк в ваших файлах. Там могут быть разные окончаниями строк: LF, CRLF, CR или микс из всех них, но Гиту это будет безразлично. Такое значение может привести к тому, что диффы станут менее читаемыми и появятся сложности при слиянии веток. У большинства пользователей Unix/Linux установлено именно это значение, потому что у них нет проблем с CRLF и им не нужно, чтобы Гит делал дополнительную работу каждый раз при записи файлов в базу данных или в рабочую папку.
• core.autocrlf = true — значит, что Гит обработает все текстовые файлы и убедится, что все CRLF заменены на LF перед записью в базу данных. При обратном процессе он преобразует все LF в CRLF.
  Такая установка гарантирует, что ваш репозиторий можно будет использовать на других платформах, сохраняя CRLF в вашем рабочей папке. Поэтому параметр true для core.autocrlf рекомендован для Windows.
• core.autocrlf = input — значит, что Гит обработает все текстовые файлы и убедится, что все CRLF изменены на LF при записи файлов в базу данных. Однако обратной замены не произойдёт. При записи файлов в рабочую папку из базы данных, для обозначения конца строки останутся LF.
  Этот параметр обычно используется в Unix / Linux / OS X для предотвращения записи CRLF в репозиторий. Идея заключается в том, что если вы вставили код из браузера и случайно записали CRLF в один из ваших файлов, Гит удостоверится, что произойдёт замена на LF при записи в базу данных.

Чтобы увидеть, какое значение для core.autocrlf установлено в вашей системе, нужно запустить в командной строке git config --global core.autocrlf .
Если команда ничего не вернёт, то вы используете значение по умолчанию, false.

Как же Гит определяет, что файл текстовый? Хороший вопрос. У Гита есть внутренний эвристический метод, который проверяет, двоичный ли файл. Если файл не двоичный, то Гит считает его текстовым. Но Гит иногда может ошибаться, и это будет причиной для знакомства со следующей настройкой.

Параметр core.safecrlf был создан на тот случай, если Гит ошибётся и изменит окончания строк там, где лучше было бы оставить их в покое.

• core.safecrlf = true — перед записью в базу данных при подготовке к замене CRLF на LF, Гит убедится, что сможет успешно прервать операцию. Он проверит, что можно откатить изменения (из LF в CRLF), а если нет, то отменит операцию.
• core.safecrlf = warn — сделает то же, что и предыдущий параметр, но вместо того, чтобы прервать операцию, Гит просто предупредит вас о том, что может случиться что-то нехорошее.

Наконец, вы можете создать в корне своего репозитория файл .gitattributes и указать в нём настройки для конкретных файлов. Это позволит вам управлять такими настройками, как autocrlf для каждого типа файлов.

• Например, для того, чтобы Гит заменил CRLF на LF во всех текстовых файлах, можно написать в .gitattributes такую строку:

  *.txt crlf.

• Или можно сделать, чтобы Гит никогда не заменял CRLF на LF в текстовых файлах с помощью такой строки:

  *.txt -crlf

• Чтобы Гит заменял CRLF на LF в текстовых файлах только при записи в базу данных, но возвращал LF при записи в рабочий каталог, нужно написать:

  *.txt crlf=input

Хорошо, видите, какой беспорядок мы тут учинили? И он становится ещё больше, если мы начинаем работать над проектами, которые подталкивают нас к другим глобальным настройкам.
Введём в дело новую систему, доступную начиная с версии Гит 1.7.2.

Новая система

Новая система определяет все настройки для окончаний строк в файле .gitattributes вашего репозитория, инкапсулируя их внутри и делая независимыми от глобальных настроек.

В новой системе за то, чтобы указать Гиту, в каких файлах надо заменить CRLF на LF, отвечаете вы, сообщая об этом с помощью атрибута text в файле .gitattributes. В этом случае будет полезен мануал для .gitattributes, а ниже вы найдёте несколько примеров использования атрибута text.

• *.txt text — устанавливает атрибут text для всех текстовых файлов. Это значит, что Гит будет запускать процесс замены CRLF на LF каждый раз при записи в БД и делать обратную замену при выводе из базы данных в рабочий репозиторий.
• *.txt -text — снимет со всех текстовых файлов этот фильтр. Это значит, что в указанных файлах не будет замены CRLF на LF.
• *.txt text=auto — установит для всех, подходящих под условие файлов, замену CRLF на LF, если Гит с помощью своего эвристического метода определит эти файлы как текстовые, а не бинарные.

Если файл не определён, Гит вернётся к старой системе и настройке core.autocrlf.

Именно так работает обратная совместимость, но я рекомендую, особенно тем, кто использует Windows для разработки, явно создавать файл .gitattributes.

Ниже пример файла .gitattributes с общими настройками, который можно использовать для своего проекта. Пример взят отсюда.

# Общие настройки, которые всегда должны быть использованы для настроек вашего языка.
# Автоматическое определение текстовых файлов и выполнение нормализации LF 
# http://davidlaing.com/2012/09/19/customise-your-gitattributes-to-become-a-git-ninja/
* text=auto

#
# Строка выше будет обрабатывать все файлы, которых нет в списке ниже.
#

# Documents
*.doc     diff=astextplain
*.DOC     diff=astextplain
*.docx diff=astextplain
*.DOCX diff=astextplain
*.dot  diff=astextplain
*.DOT  diff=astextplain
*.pdf  diff=astextplain
*.PDF     diff=astextplain
*.rtf     diff=astextplain
*.RTF     diff=astextplain
*.md text
*.tex text
*.adoc text
*.textile text
*.mustache text
*.csv text
*.tab text
*.tsv text
*.sql text

# Graphics
*.png binary
*.jpg binary
*.jpeg binary
*.gif binary
*.tif binary
*.tiff binary
*.ico binary
# SVG по дефолту рассматривается как бинарный. Если вы хотите, чтобы он распознавался как текст, закомментируйте  следующую строку и раскомментируйте следующую за ней.
*.svg binary
#*.svg text
*.eps binary

#
# Исключить файлы из экспорта
#

.gitattributes export-ignore
.gitignore export-ignore

Как вы могли заметить, с помощью следующей команды можно сказать Гиту обнаруживать все текстовые файлы и автоматически конвертировать в них CRLF в LF:

* text=auto

Это, конечно, лучше, чем требовать от всех одной глобальной настройки для core.autocrlf, но и означает, что вы полностью доверяете Гиту в определении бинарности файлов. На наш взгляд, лучше явно указать текстовые файлы, которым требуется нормализация. Если вы собираетесь использовать этот параметр, не забудьте, что он должен быть указан на первой строке файла .gitattributes, чтобы последующие строки могли его переопределить.

22 ответа

tr -d '15' <DOS-file >UNIX-file

sed 's/^M$//'     # DOS to Unix
sed 's/$/^M/'     # Unix to DOS

tr -d "r" < file

# IN UNIX ENVIRONMENT: convert DOS newlines (CR/LF) to Unix format.
sed 's/.$//'               # assumes that all lines end with CR/LF
sed 's/^M$//'              # in bash/tcsh, press Ctrl-V then Ctrl-M
sed 's/x0D$//'            # works on ssed, gsed 3.02.80 or higher

# IN UNIX ENVIRONMENT: convert Unix newlines (LF) to DOS format.
sed "s/$/`echo -e \r`/"            # command line under ksh
sed 's/$'"/`echo \r`/"             # command line under bash
sed "s/$/`echo \r`/"               # command line under zsh
sed 's/$/r/'                        # gsed 3.02.80 or higher

ex -bsc '%!awk "{sub(/r/,"")}1"' -cx file

ex -bsc '%!awk "{sub(/$/,"r")}1"' -cx file

awk '{ sub("r$", ""); print }' dos.txt > unix.txt

perl -pe 's/r$//' < dos.txt > unix.txt

perl -pe 'if ( s/rn?/n/g ) { $f=1 }; if ( $f || ! $m ) { s/([^n])z/$1n/ }; $m=1' PCfile.txt

#!/usr/bin/env python
"""
convert dos linefeeds (crlf) to unix (lf)
usage: dos2unix.py <input> <output>
"""
import sys

if len(sys.argv[1:]) != 2:
  sys.exit(__doc__)

content = ''
outsize = 0
with open(sys.argv[1], 'rb') as infile:
  content = infile.read()
with open(sys.argv[2], 'wb') as output:
  for line in content.splitlines():
    outsize += len(line) + 1
    output.write(line + 'n')

print("Done. Saved %s bytes." % (len(content)-outsize))

#!/usr/bin/env bash
perl -pi -e 's/rn/n/g' -- [email protected]

awk -v ORS='rn' '1' unix.txt > dos.txt

while IFS= read -r line;
do printf '%sn' "${line%$'r'}";
done < dos.txt > unix.txt

dos2unix <filename>

dos2unix -n <input-file> <output-file>

$ echo -e "abcr" >tst.txt
$ file tst.txt
tst.txt: ASCII text, with CRLF line terminators
$ sed -i "" tst.txt
$ file tst.txt
tst.txt: ASCII text

vim file.txt -c "set ff=unix" -c ":wq"

vim file.txt -c "set ff=dos" -c ":wq"

tr "r" "n" < sampledata.csv > sampledata2.csv 

perl -pe 's/rn/n/; s/([^n])z/$1n/ if eof' PCfile.txt

zip -ll textfiles-lf.zip files-with-crlf-eol.*
unzip textfiles-lf.zip 

zip --help
...
-l   convert LF to CR LF (-ll CR LF to LF)

awk 'BEGIN{RS="r|n|rn|nr";ORS="n"}{print}' windows_or_macos.txt > unix.txt

brew install dos2unix

for csv in *.csv; do dos2unix -c mac ${csv}; done;

sed --expression='s/rn/n/g'

sed 's/^M/
/g' < ffmpeg.log > new.log

sed 's/^V^M/^V^J/g' < ffmpeg.log > new.log

sed '/^M$/! s/$/^M/'

iconv -f UTF-16LE -t UTF-8 [filename.txt]
-f from format type
-t to format type

find . -name "*.sql" -exec iconv -f UTF-16LE -t UTF-8 {} -o ./{} ;