Подтвердить что ты не робот

Групповой агностический diff?

Я работаю над mac, с некоторыми довольно старыми файлами. Различные файлы были созданы разными программами, поэтому некоторые из них заканчиваются на \r (mac) и некоторые с \n (unix). Я хочу иметь возможность запускать такие команды, как diff, grep и т.д., Но те, которые имеют \r, рассматриваются как одна гигантская линия. кто-нибудь знает версию diff, grep и т.д., которая будет корректно работать со всеми новыми строками?

ETA: Я также хотел бы, чтобы они были утилитами unix, поэтому я могу использовать их в скриптах, emacs и т.д.

4b9b3361

Ответ 1

Как сказал Джей, Diff'nPatch кажется тем, что вы ищете. В качестве альтернативы вы можете конвертировать все ваши окончания строк \'' в '\n' в одну команду следующим образом:

sed -ie 's/\r/\n/' filename

или

find . | xargs -n1 sed -ie 's/\r/\n/'

(В последнем случае вы можете каким-либо образом отфильтровать список файлов или применить его ко всем файлам во всех подкаталогах.)

Ответ 2

Если вы используете diff -w, он игнорирует пробелы в файлах, что, вероятно, достаточно для ваших нужд.

РЕДАКТИРОВАТЬ: только что понял, что я неправильно прочитал сообщение в первый раз, и вы действительно ищете diff, который будет работать с завершением строки \r. Мое предложение состояло в том, чтобы преобразовать файлы с помощью flip, который может конвертировать файлы в стандартный формат \n.

EDIT 2: просто нашел что-то похожее на то, что вы хотите - Diff'nPatch:

Diff'nPatch - это порт для Macintosh GNU 'diff', 'patch' и 'cmp' коммунальные услуги. Это позволяет сравнивать и найти различия между двумя файлами или папки, сортировать два файла, генерировать diff в различных форматах (обычный, контекст, unidiff и т.д.), применяются патчи, сравнить байты по байтам. Он может обрабатывать любые типы строк (mac, unix или windows)

Ответ 3

Утилита diff, поставляемая с OSX Lion, имеет опцию "strip-trailing-cr", которая делает то, что вы хотите. Вы используете его так:

diff -cpt a.c b.c --strip-trailing-cr

Ответ 4

PHPStorm diff view "игнорировать пробелы" просто работает. Он автоматически игнорирует различия в возврате каретки /EOL/newline/what -have-you. Вы можете тратить время на вождение тайными командами unix или что-то еще, или вы могли бы просто получить то, что действительно работает и двигаться вперед с жизнью.

  • Использование любого из вышеупомянутых решений не удалось на Mountain Lion (включая тот, который был отмечен как правильный ответ). Все ссылки для скачивания для "Diff-npatch" не удались. (Я нашел http://webperso.easyconnect.fr/bdesgraupes/tools.html, но мне действительно не нравится идея прибегнуть к использованию инструмента diff, который нельзя вызвать из командной строки и, таким образом, интегрированы с любым инструментом IDE или VCS, который я мог бы использовать, например BBEdit, SourceTree или SmartSVN, - все из которых, BTW, не смогли игнорировать новые строки с помощью встроенного инструмента сравнения.

Да, мои новые строки -\r, но что? Arrr! Если программное обеспечение слишком глупо, чтобы понять, что \r ==\n, то я просто собираюсь использовать другое программное обеспечение, достаточно умное.

PHPStorm - единственное программное обеспечение, в котором есть инструмент для разграничения, который "просто сработал" - что я и ожидал от программного обеспечения Mac. Я ожидаю, что программное обеспечение Mac просто будет работать. Я использую Mac, поэтому я могу выполнять свою работу вместо того, чтобы изучать тайные команды терминала на каждом шагу, которые почти все плохо документированы, ожидая, что вы просто поймете, как команды должны быть отформатированы без каких-либо четких примеров, поэтому вы никогда не знаете, вы делаете это неправильно или команда просто не работает так же, как и все другие плохие программы. Возьмите этот пример из "man diff":

   -I RE  --ignore-matching-lines=RE
          Ignore changes whose lines all match RE.

Хорошо, поэтому, прочитав это, я понятия не имею, что это значит. Нет примера его использования. Что такое "RE"? Он нигде не говорит.

Тогда вот эта драгоценность:

  --GTYPE-group-format=GFMT
          Similar, but format GTYPE input groups with GFMT.

   --line-format=LFMT
          Similar, but format all input lines with LFMT.

   --LTYPE-line-format=LFMT
          Similar, but format LTYPE input lines with LFMT.

   LTYPE is `old', `new', or `unchanged'.
          GTYPE is LTYPE or `changed'.

          GFMT may contain:

   %<     lines from FILE1

   %>     lines from FILE2

   %=     lines common to FILE1 and FILE2

   %[-][WIDTH][.[PREC]]{doxX}LETTER
          printf-style spec for LETTER

          LETTERs are as follows for new group, lower case for old group:

   F      first line number

   L      last line number

   N      number of lines = L-F+1

   E      F-1

   M      L+1

          LFMT may contain:

   %L     contents of line

   %l     contents of line, excluding any trailing newline

   %[-][WIDTH][.[PREC]]{doxX}n
          printf-style spec for input line number

          Either GFMT or LFMT may contain:

   %%     %

   %c'C'  the single character C

   %c'\OOO'
          the character with octal code OOO

Я бы не имел никакого смысла в этом отрывке. Что такое "enter"? Это оба файла или только файл "to" или просто "из" файла? Что такое "похоже"? Что означает "есть" в предложении, "GFMT" - это "LTYPE" или "изменено"? Означает ли это, что "может быть заменено на"? Если да, то почему не "GFMT" в цитатах или скобках и т.д.? Поскольку ни один пример не приведен, нет никакого способа узнать; формулировка документации совершенно неоднозначна. Что означает "GFMT может содержать"... означает? "Содержит" означает, что текст, заменяющий аббревиатуру GFMT, может содержать это? Без четкого примера это совершенно бесполезно.

Зачем даже писать справочную страницу, если вы собираетесь сделать ее настолько загадочной и двусмысленной, что она бесполезна для всех, кто еще не знает, как использовать программное обеспечение? В этот момент это не руководство; это просто страница с быстрой ссылкой для парней, которые написали программное обеспечение, чтобы они могли вспомнить, как его использовать. Я предполагаю, что они предполагают, что вы просто прочитаете исходный код, если хотите узнать, что он на самом деле делает.

Мое время ценно. Я бы предпочел просто заплатить деньги за то, что у вас есть программное обеспечение, которое действительно работает правильно и имеет соответствующую документацию.

Потому что все это не удалось:

 diff -d --strip-trailing-cr --ignore-all-space --from-file=rest.phtml test.phtml

... не удалось игнорировать символы \r.

 diff -wd --strip-trailing-cr --ignore-all-space --from-file=rest.phtml test.phtml

... не удалось игнорировать символы \r.

 diff -wd --suppress-common-lines --strip-trailing-cr --ignore-all-space --from-file=rest.phtml test.phtml

... не удалось игнорировать символы \r.

 diff -wd test.phtml rest.phtml --suppress-common-lines --strip-trailing-cr --ignore-all-space

... не удалось игнорировать символы \r.

 diff -awd test.phtml rest.phtml --suppress-common-lines --strip-trailing-cr --ignore-all-space

... не удалось игнорировать символы \r.

В этом случае, если они были \n символами, это также потерпело неудачу при добавлении \n символов.

Где test.phtml ==

Foo

бар

и rest.html ==

Foobar

Команда "diff" всегда дает вам что-то вроде:


* 1,2 **! foo! bar\No newline в конце файла

--- 1 ----! foobar\No newline в конце файла

... сбой!

Ответ 5

Команда dos2unix может помочь в преобразовании ваших файлов в согласованный формат. Я считаю, что он доступен практически для каждой платформы, о которой вы можете думать, и может запускать сразу множество файлов. Я считаю, что пакет доступен для Mac.

Ответ 6

Я использовал следующее быстрое исправление, которое имеет недостатки (см. ниже):

1: выполните diff и перечислите только имена файлов

diff -r -q dir1/ dir2/

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

3: выполните регулярный diff

Недостатки включают:

  • менее надежный, подверженный ошибкам
  • больше работы, если у вас много файлов