Вышла (http://savannah.gnu.org/forum/forum.php?forum_id=7132) новая версия популярной утилиты для организации поиска данных в текстовых файлах - GNU Grep 2.11. В новой версии обеспечена возможность поиска с перебором всех файлов в текущей директории, если не указан файловый операнд и указана опция эквивалентная "-r" ("--recursive"). Ранее, если не указать файловый операнд, утилита grep игнорировала опцию "-r" и осуществляла нерекурсивный поиск в стандартном входном потоке. Вторым добавленным новшеством является реализация выделения цветом совпадений на платформе Windows.
Некоторые другие изменения:- Прекращение выполнения после первой ошибки записи, вместо неоднократного продолжения попыток. - Исправлена большая порция ошибок, например, устранён крах при чтении строки, размер которой не укладывается в тип int (2 Гб для 64-разрядных систем).- При попытке обработать директорию вместо файла (например, "grep x .") теперь не игнорируются ошибки.- Добавлено распознавание за...
URL: http://savannah.gnu.org/forum/forum.php?forum_id=7132
Новость: http://www.opennet.me/opennews/art.shtml?num=33249
хорошая и нужная тулза для скриптов, но cmd | perl -e '...' уже давно привычнее
> perlи весит-то немного
Вы, чтобы карандаш очинить, тоже мельничный жернов берете?
Нет конечно. Гораздо чаще приходится сталкиваться с чем-то посложнее чем cmd | grep 'REX' | ... . И в таких случаях как-то быстрее и приятнее работать с perl.
На этот случай есть egrep/fgrep. Удивлены?
Нет. Есть perl в который всегда можно добавить любую логику и это не потребует сношения с grep,egrep/fgrep/sed/awk,find и, что еще хуже, смены инструментов при внезапном изменении требовании к фильтру (что кстати очень часто). На среднем уровне с coreutils я вполне спокойно работаю, но когда потенциально возможны сложности (пусть и маловероятны), то тут выбор очевиден.
> Нет. Есть perl в который всегда можно добавить любую логику и это
> не потребует сношения с grep,egrep/fgrep/sed/awk,find и, что еще хуже, смены инструментов
> при внезапном изменении требовании к фильтру (что кстати очень часто). На
> среднем уровне с coreutils я вполне спокойно работаю, но когда потенциально
> возможны сложности (пусть и маловероятны), то тут выбор очевиден.Удивитесь еще больше. Борн/Корн/Баш - Тьюринг-полные интерпретаторы с ЛЮБОЙ логикой. Опачки?
тут мы должны обратиться к истории и попытаться разобраться в причинах побудивших к созданию perl (ранее pearl).
Напомните? Там что-то про извращенияя?... :)
Нет, как обычно, причина банальна до одури - фатальный недостаток.
Хочешь сравнить возможности bash 1995 года и последнего?
Хочешь продемонстрировать IPC в баше?
> Хочешь продемонстрировать IPC в баше?Это несомненно крайне необходимая фича для грепинга текста <img src=trollface.jpg>
IPC то конечно не нужен, но для парсинга чуть более сложного html-кода - без перла никуда.
<Img
border=
0 SRC
=troll face©.jpg
>$ cat 1.html | perl -MHTML::Parser -Mencoding=utf8 -e 'HTML::Parser->new(start_h => [sub {print "$_[1]->{src}\n" if $_[0] eq "img"}, "tagname, attr"])->parse_file(*STDIN)'
troll face©.jpg
хотя в данном случае все же лучше написать скрипт :)
troll face©.jpg
или perl -MHTML::TreeBuilder -Mencoding=utf8 -e 'print $_->attr('src'), "\n" for HTML::TreeBuilder->new_from_file(*STDIN)->find("img")'
Тьюринг-полнота тут не при чем, вопрос в удобстве и лаконичности. Или вы одноразовые скрипты на чистых сях пишете? А брейнфак тоже тьюринг-полный
Девиз вашей саморекламы - "пэрл! для тех, кто ниасилил bash-sed-awk + coreutils." ?
Все мы осилили (может и не в полной мере), но perl универсальнее чем каждая из утилит отдельно.
А C/C++ еще универсальней. Кстати, питонеры с вами не согласятся. Кому-то нравится поп, кому-то попадья. А кому-то свиной хрящик.
>А C/C++ еще универсальнейС (Си) - да, С++ - нет (хотя если программировать смешивая объектный и процедурный стили с низкоуровневыми хаками - то С++ не будет уступать Си).
>Кстати, питонеры с вами не согласятся
Не удивительно. Философия питона их учит только одной религии и призывает быть линейным, однозначным, услужливым и послушным мальчиком :).
PS: TIMTOWTDI, man !
> Не удивительно. Философия питона их учит только одной религии и призывает быть
> линейным, однозначным, услужливым и послушным мальчиком :).Ну в общем дешевым взаимозаменимым корпоративным ботом, по цене рубль за пачку.
> PS: TIMTOWTDI, man !Именно поэтому perl и сдох. Туда ему и дорога :-P
>> PS: TIMTOWTDI, man !
> Именно поэтому perl и сдох. Туда ему и дорога :-PСтранная логика для "маргинальщика". :-]
>>> PS: TIMTOWTDI, man !
>> Именно поэтому perl и сдох. Туда ему и дорога :-P
> Странная логика для "маргинальщика". :-]TIMTOWTDI внутри *одного* ЯП приводит только к разнузданности
и нарушению дисциплины.
Моя маргинальщина нелюбви к перлу не противоречит.
>TIMTOWTDI внутри *одного* ЯП приводит только к разнузданностии нарушению дисциплины.
Из вас получится хороший винтик в обычной корпоративной машине. Остальным: TIMTOWTDI внутри одного ЯП обеспечивает возможности выбора. Вам, кстати, роднее среда с возможностью выбора или без оной (когда за вас все уже решили/навязали) ? Впрочем, если вам надо без возможности выбора (возможно зря я прошлое предложение написал), то не отвечайте вовсе - я за вас решу сам.
> Остальным: TIMTOWTDI внутри одного ЯП обеспечивает
> возможности выбора. Вам, кстати, роднее среда с возможностью
> выбора или без оной (когда за вас все уже решили/навязали) ?Массовый отказ от перла с приходом новых языков произошел
по вполне объективным причинам. Предлагаю на досуге о них задуматься.
Раз уж Вам так нравится выбор, я не буду навязывать свое видение...Но TIMTOWTDI -- причина всего остального.
>Массовый отказ от перла с приходом новых языков произошел по вполне объективным причинамПроизошел по одной причине, по которой скоро будет отказ от PHP в пользу ECMAScript, а потом отказ от ECMAScript. Причина проста: начинающие (!) программисты думают что всегда проще написать свою реализацию Linux Kernel чем разобраться в существующем коде. А если учесть, что к массовому наплыву быдлокодеров и быдлопользователей в интернеты уже был приличный объем кода и разнокалиберных библиотек и готовых решении на Perl, то вполне логично что вместо того чтобы разбираться с существующим (а это сложно) - быдлокодеры ушли в PHP, где начали обильно плодить быдлокод. А сейчас придет новое поколение, которому надо кушать и самый легкий путь - вытеснять PHP (ниша заполнена) в пользу JScript. Корпорации это тем более на руку, т.к. нанять "зеленого" студента сцеплять классы на JScript за 2 рубля куда выгоднее чем нанимать уже опытного PHP'шника (который себе уже цену знает). А что мне сказать про perl-программиста который осилил TIMTOWTDI не только относительно синтаксиса, но и относительно техник построения сложных систем (да-да, есть несколько(!) распространенных моделей построения) ?
> TIMTOWTDI внутри одного ЯП обеспечивает возможности выбора.К сожалению, в перле TIMTOWTDI относится скорее к синтаксису, нежели чем к семантике. Гораздо лучше, чтобы было наоборот
TIMTOWTDI относится не только к синтаксису, но и к семантике. Стоит ли мне говорить что Perl не навязывает определенный стиль программирования как и Си. И стоит ли мне указывать пальцем на людей которые рефлексируют на синтаксис perl из-за TIMTOWTDI ? И, скажите мне пожалуйста, как вы осиливаете код проектов на Си где все обильно обложено макросами и язык легко позволяет это делать (чем не TIMTOWTDI ?). Вот сколько не говорите - но я вас, неосиляторов, синтаксиса perl непонимаю. Что, у вас на самом деле возникают сложности с синтаксисом языка? Ну а сложности конструируемой системы, по-видимому, за вас уже инкапсулировали в классы и вы об этом никогда не знаете, так?
> TIMTOWTDI внутри *одного* ЯП приводит только к разнузданности и нарушению дисциплины.
> Моя маргинальщина нелюбви к перлу не противоречит.На рхел внутри одного POSIX -- шагом-арш!
(привет от другого "маргинальщика", ага :)
Perl сдох как сдох Linux? Пиши как есть: перл сдох среди быдлокодеров. Сейчас perl-сообщество ушло в тень. Вцелом же, скажу что за последние неск. лет есть положительный тренд в разработке perl'а и его модулей. Если не вершишь - можешь сам рассчитать график stabel и dev релизов перла.
> Все мы осилили (может и не в полной мере), но perl универсальнее
> чем каждая из утилит отдельно.Но утилиты всегда есть - а перловку ещё ставить придётся.
> Но утилиты всегда есть - а перловку ещё ставить придётся.Перловку в большинстве виденных случаев просто так не снесёшь.
как не гадко поддерживать анонима ... перл это вещь, также пользуюсь регулярно. но ни один из моих коллег по нескольким крупным конторам не осилил, по причине чего пришлось и мне для унификации по возможности решать через sed|awk|grep|cut etc...
-
справедливости ради перл как инструмент для обработки строк в тыщу раз универсальнее, удобнее и логичнее шеловских костылей, но на небольших задачах можно обойтись и ими. ну и да, один и тот же скрипт на костылях шела может напороться на разные ключи костылей в Linux, AIX и солярке ...
_
ИМХО
> напороться на разные ключи костылей в Linux, AIX и соляркеЕсть вполне определенные стандарты для переносимого скриптинга на шелл.
cmd | perl6 -e '...'
Попробуй так, бро. Так перспективнее.
>Так перспективнее.Не думаю. Мода на ООП головного мозга проходит. Perl (5) много ближе к Си чем 6й. Ну а полезные фичи 6ого портируются в 5й. Так что ..
мда, я знал что стоит поставить тег "сарказм"
Ты прав. Лично я сарказма как-то не увидел.
> хорошая и нужная тулза для скриптов, но cmd | perl -e
> '...' уже давно привычнееОткройте для себя grep -P
-P, --perl-regexp
Interpret PATTERN as a Perl regular expression (PCRE, see below). This is highly experimental and grep -P may warn of unimplemented
features.Хотя эта фича есть только в gnu grep => скрипты с ней непортабельны.
Но для личного использования - вполне.
>Откройте для себя grep -PОткройте для себя сообщение #9. Никакое сочетание из множества [ivGFEPf] не дает возможность быстро и безболезненно запрограммировать сложные логики. Grep годится только под простые задачи уровня линейной фильтрации - не более.
Похоже вы и без goto тоже программу написать не умеете.Для одноразового костыля вне зависимости от его поморочености всегда хватало bash+sed+awk+grep. Во всяком случае я на этом деле ожнажды сделал парсер детализаций телефонн6ых звонков, их нарезку на куски и последующую рассылку по списку пациентам (для чего рожал письма с аттачами и сопроводительным текстом), пока программеры в биллинге это дело фиксили. А да, команда sendmail мне понадобилась еще. Для рассылки.
Unix way. Работы заняло на два часа вместе с отладкой. Мог бы написать на перле, но лениво было трахаться.
>Похоже вы и без goto тоже программу написать не умеете.Вы ошиблись. Скорее вы делаете скоропостижные выводы руководствуясь поверхностными суждениями.
>Для одноразового костыля вне зависимости от его поморочености всегда хватало bash+sed+awk+grep. Во всяком случае я на этом деле ожнажды сделал парсер детализаций телефонн6ых звонков, их нарезку на куски и последующую рассылку по списку пациентам (для чего рожал письма с аттачами и сопроводительным текстом), пока программеры в биллинге это дело фиксили. А да, команда sendmail мне понадобилась еще. Для рассылки.
Одноразовые костыли навроде нарезки линейно-отфильтрованного текста я тоже делаю с использованем grep, split, .. (по надобности). Ну а если текст требует сложного фильтра и/или еще и обработки части текста то тут уже только perl (можно конечно на чем угодно - хоть на tcsh, но на perl получается почему-то быстрее, лаконичнее и проще).
split и cut попутали.
Очередной с поспешными выводами: во-первых, вы не разглядели многоточие и, во-вторых, откройте для себя опции к split.
>Grep годится только под простые задачи уровня линейной фильтрации - не более.А что в man grep утверждается то то обратное?
Парень ты серьёзно болен.
> Откройте для себя сообщение #9. Никакое сочетание из множества [ivGFEPf] не дает
> возможность быстро и безболезненно запрограммировать сложные логики. Grep годится только
> под простые задачи уровня линейной фильтрации - не более.А Вы для себя команду М-х grep в Емаксе не открывали? Преудобнейшая штуковина, доложу Вам.
А perl -- он конечно хорош и силен. Сам для сравнительно простых вещей обхожусь bash|awk|sed|grep|tr|cut..find да же perl -e '' (также на участках текста в емаксе M-1-M-|). Но и сбацать на awk-grep-sed в этом случае намного проще (а find в перле не хватает )
И да, perl -- является часто является зависимым пакетом на Лине (даже на фряхе).
В общем, все они друг друга дополняют.
К сказанному:
> вещей обхожусь bash|awk|sed|grep|tr|cut..findеще head и особенно tail хороши, sort...
Только вот perl -e намного тормознее grep на простом поиске. И это не какая-то абстракция - это реально заметно, разница в несколько раз по скорости между grep'ом и другими искалками. Например, очень часто grep находит моментально, открываешь в less, ищещь - и ждеееешь.А причина проста - http://swtch.com/~rsc/regexp/regexp1.html
Это очень полезная статья. Надо будет perl-сообществу показать ее, только сначала разобраться в этом.
> перловые регехпы - самые гибкие а не самые быстрые.В подавляющем большинстве случаев "гибкость" перловых регекспов,
которая приводит к неизбежной экспоненте в трудоемкости, не нужна.
Вот для этих случаев перловодам и следовало бы сделать нормальную,
с точки зрения скорости работы, реализацию.
сравните результатыtime grep -h "#include.*stdio" /usr/include/{*.h,*/*.h}
time awk '/#include.*stdio/ {print}' /usr/include/{*.h,*/*.h}
time sed -n '/#include.*stdio/p' /usr/include/{*.h,*/*.h}
time perl -e '/#include.*stdio/ && print while <>' /usr/include/{*.h,*/*.h}перл только грепу и проигрывает, и то - не фатально.
и это с учетом того, что в одиночку греп - пустое место.
> сравните результаты
> time grep -h "#include.*stdio" /usr/include/{*.h,*/*.h}
> time awk '/#include.*stdio/ {print}' /usr/include/{*.h,*/*.h}
> time sed -n '/#include.*stdio/p' /usr/include/{*.h,*/*.h}
> time perl -e '/#include.*stdio/ && print while <>' /usr/include/{*.h,*/*.h}
> перл только грепу и проигрывает, и то - не фатально.
> и это с учетом того, что в одиночку греп - пустое место.Повторение -- мать учения.
Для общего развития хотя бы.http://swtch.com/~rsc/regexp/regexp1.html
http://swtch.com/~rsc/regexp/regexp2.html
http://swtch.com/~rsc/regexp/regexp3.html
> В подавляющем большинстве случаев "гибкость" перловых регекспов,
> которая приводит к неизбежной экспоненте в трудоемкости, не нужна.я вам дал простой "негибкий" пример, который не приводит к экспоненте ни в трудоемкости ни в ресурсоемкости. в нем перл обгоняет GNU awk и GNU sed.
чем вы опять недовольны?вот еще бенчмарк до кучи.
http://lh3lh3.users.sourceforge.net/reb.shtml
> я вам дал простой "негибкий" пример, который не приводит к экспоненте ни
> в трудоемкости ни в ресурсоемкости.Статьи, надо понимать, не прочитаны.
Ясно, разговор этот бесполезен.
Хотя, если нет понимания того, что такое
"трудоемкость алгоритма", на что можно было надеяться...> в нем перл обгоняет GNU awk и GNU sed.
> чем вы опять недовольны?Тупым упрямством собеседника.
Мне мало интересны бенчмарки на регекспах в 10 символов.> вот еще бенчмарк до кучи.
> http://lh3lh3.users.sourceforge.net/reb.shtmlЧитаешь книгу, а видишь фигу.
Сравни цифры в _последней_ колонке и строках
с пометкой BT и FSA.
> сравните результатыЗабыли сперва всё cat'нуть куда-нить в /dev/null, чтоб не первая команда из замеряемых отвечала за кэш.
cat /usr/include/{*.h,*/*.h} > /dev/null 0.01s user 0.06s system 5% cpu 1.274 total
> time grep -h "#include.*stdio" /usr/include/{*.h,*/*.h}
0.01s user 0.03s system 78% cpu 0.051 total
> time awk '/#include.*stdio/ {print}' /usr/include/{*.h,*/*.h}
0.08s user 0.02s system 94% cpu 0.110 total
> time sed -n '/#include.*stdio/p' /usr/include/{*.h,*/*.h}
0.13s user 0.03s system 97% cpu 0.169 total
> time perl -e '/#include.*stdio/ && print while <>' /usr/include/{*.h,*/*.h}
0.09s user 0.03s system 91% cpu 0.131 total
> перл только грепу
...с awk...
> и проигрывает, и то - не фатально.
Угу, в два с половиной раза по ходикам на стенке при предложенных Вами условиях на ноуте под руками.
Хотя осмысленно было бы сделать серию забегов на различных массивах данных, чтобы разделить время инициализации и время собственно работы.
> и это с учетом того, что в одиночку греп - пустое место.
Для данной задачи греп как раз минимально непустое место, бишь оптимальное. При всём моём уважении к перлу.
>> сравните результаты
> Забыли сперва всё cat'нуть куда-нить в /dev/null, чтоб не первая команда из
> замеряемых отвечала за кэш.условия для всех одинаковые, так что не думаю, что это принципиально
> ...с awk...
многое зависит от версии тулз и содержимого /usr/include
gawk/squeeze uptodate 1:3.1.7.dfsg-5
grep/squeeze uptodate 2.6.3-3
perl/squeeze uptodate 5.10.1-17squeeze3
sed/squeeze uptodate 4.2.1-7Linux debian 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC 2011 x86_64 GNU/Linux
http://pastebin.com/xH7Lj03m
http://pastebin.com/QLqhQ74Q>> и проигрывает, и то - не фатально.
> Угу, в два с половиной раза по ходикам на стенке при предложенных
> Вами условиях на ноуте под руками.более того скажу, перл на простых примерах может отстать от грепа в 10 и больше раз
>> и это с учетом того, что в одиночку греп - пустое место.
> Для данной задачи греп как раз минимально непустое место, бишь оптимальное.
> При всём моём уважении к перлу.для данной задачи - лучше перла я бы и сам ничего не придумал
но вопрос стоял примерно так: насколько ресурсоемка будет конструкция cmd | perl по сравнению с cmd | grep | awk | cut | sed ...cmd | grep
потом, при усложнении выражения добовляешь
cmd | grep | awk
потом понимаешь что лучше сделать
cmd | sed | cut | trт.е., как кто-то заметил выше, приходится менять инструмент
перл как минимум умеет все, что умеют вышеперечисленные тулзы, так что когда нужно сделать более менее сложную выборку, лично я начинаю именно с перла
> для данной задачи - лучше перла я бы и сам ничего не
> придумалгрепа, разумеется, пардон :)
>>> сравните результаты
>> Забыли сперва всё cat'нуть куда-нить в /dev/null, чтоб не первая команда из
>> замеряемых отвечала за кэш.
> условия для всех одинаковые, так что не думаю, что это принципиальноВы же понимаете, что это верно при наличии всех затрагиваемых файлов в кэше, а сами по себе они туда обычно не запрыгивают?
> многое зависит от
(текущий сизиф, 3.2.9-std-pae-alt1 i686, C2D/i965, Kingston SNVP325-S2/128GB)
> версии тулз
gawk-3.1.8-alt1
sed-4.2.1-alt3
grep-2.10-alt1
perl-base-5.14.2-alt4> и содержимого /usr/include
/usr/include/{*.h,*/*.h} -- 951 файл общим объёмом 5028961 байт.
> http://pastebin.com/xH7Lj03m
Это уже лучше. :)
> но вопрос стоял примерно так: насколько ресурсоемка будет конструкция cmd | perl
> по сравнению с cmd | grep | awk | cut | sed ...Зависит. Наблюдал, как некоторые штуки переписывали с перла как раз на поток.
> перл как минимум умеет все, что умеют вышеперечисленные тулзы
|
> сравните результаты
> time grep -h "#include.*stdio" /usr/include/{*.h,*/*.h}...а чего тут кавычки не одинарные-то?....
> time awk '/#include.*stdio/ {print}' /usr/include/{*.h,*/*.h}
> time sed -n '/#include.*stdio/p' /usr/include/{*.h,*/*.h}awk '/.../'
sed '/.../'> time perl -e '/#include.*stdio/ && print while <>' /usr/include/{*.h,*/*.h}
perl -ne '/.../ and print'
...
Я бы ещё предложил 'time seq 1 100| xargs -IZZZ sed ...' , чтоб значащих цифр поболе.
> Это очень полезная статья. Надо будет perl-сообществу показать ее, только сначала разобраться
> в этом.перл-сообщество в курсе, ему пофигу.
Поддерживаю перловый тулз. Современные потребности уже намного больше, чем 'grep error'.
теперь что для каждой утилиты которой добавилась еще одна опция и исправлиил 1 баг будем рисовать новость?
Да, чё там, стирай.</деревянное>
> размер которой не укладывается в тип INT (2 Гб (!) для 64-разрядных систем).что, простите?
>> размер которой не укладывается в тип INT (2 Гб (!) для 64-разрядных систем).
> что, простите?Сами в шоке:
grep no longer dumps core on lines whose lengths do not fit in 'int'.
(e.g., lines longer than 2 GiB on a typical 64-bit host).
Instead, grep either works as expected, or reports an error.