URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 83405
[ Назад ]

Исходное сообщение
"Новая версия утилиты Grep 2.11"

Отправлено opennews , 03-Мрт-12 10:37 
Вышла (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


Содержание

Сообщения в этом обсуждении
"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 10:37 
хорошая и нужная тулза для скриптов, но  cmd | perl -e '...' уже давно привычнее

"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 11:04 
> perl

и весит-то немного


"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 11:43 
Вы, чтобы карандаш очинить, тоже мельничный жернов берете?

"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 11:56 
Нет конечно. Гораздо чаще приходится сталкиваться с чем-то посложнее чем cmd | grep 'REX' | ... . И в таких случаях как-то быстрее и приятнее работать с perl.

"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 12:05 
На этот случай есть egrep/fgrep. Удивлены?

"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 12:10 
Нет. Есть perl в который всегда можно добавить любую логику и это не потребует сношения с grep,egrep/fgrep/sed/awk,find и, что еще хуже, смены инструментов при внезапном изменении требовании к фильтру (что кстати очень часто). На среднем уровне с coreutils я вполне спокойно работаю, но когда потенциально возможны сложности (пусть и маловероятны), то тут выбор очевиден.

"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 12:34 
> Нет. Есть perl в который всегда можно добавить любую логику и это
> не потребует сношения с grep,egrep/fgrep/sed/awk,find и, что еще хуже, смены инструментов
> при внезапном изменении требовании к фильтру (что кстати очень часто). На
> среднем уровне с coreutils я вполне спокойно работаю, но когда потенциально
> возможны сложности (пусть и маловероятны), то тут выбор очевиден.

Удивитесь еще больше. Борн/Корн/Баш - Тьюринг-полные интерпретаторы с ЛЮБОЙ логикой. Опачки?


"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 13:08 
тут мы должны обратиться к истории и попытаться разобраться в причинах побудивших к созданию  perl (ранее pearl).

"Новая версия утилиты Grep 2.11"
Отправлено Andrey Mitrofanov , 03-Мрт-12 13:30 
Напомните? Там что-то про извращенияя?... :)

"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 14:26 
Нет, как обычно, причина банальна до одури - фатальный недостаток.

"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 22:59 
Хочешь сравнить возможности bash 1995 года и последнего?

"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 04-Мрт-12 19:37 
Хочешь продемонстрировать IPC в баше?

"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 05-Мрт-12 11:02 
> Хочешь продемонстрировать IPC в баше?

Это несомненно крайне необходимая фича для грепинга текста <img src=trollface.jpg>


"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 06-Мрт-12 02:57 
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

хотя в данном случае все же лучше написать скрипт :)


"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 06-Мрт-12 02:59 
troll&#32;face&copy;.jpg

"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 06-Мрт-12 03:16 
или perl -MHTML::TreeBuilder -Mencoding=utf8 -e 'print $_->attr('src'), "\n" for HTML::TreeBuilder->new_from_file(*STDIN)->find("img")'

"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 23:32 
Тьюринг-полнота тут не при чем, вопрос в удобстве и лаконичности. Или вы одноразовые скрипты на чистых сях пишете? А брейнфак тоже тьюринг-полный

" утилиты Grep 2.11"
Отправлено Andrey Mitrofanov , 03-Мрт-12 12:10 
Девиз вашей саморекламы - "пэрл! для тех, кто ниасилил bash-sed-awk + coreutils." ?

" утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 12:12 
Все мы осилили (может и не в полной мере), но perl универсальнее чем каждая из утилит отдельно.

" утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 12:32 
А C/C++ еще универсальней. Кстати, питонеры с вами не согласятся. Кому-то нравится поп, кому-то попадья. А кому-то свиной хрящик.

" утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 13:15 
>А C/C++ еще универсальней

С (Си) - да, С++ - нет (хотя если программировать смешивая объектный и процедурный стили с низкоуровневыми хаками - то С++ не будет уступать Си).

>Кстати, питонеры с вами не согласятся

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

PS: TIMTOWTDI, man !


" утилиты Grep 2.11"
Отправлено Аноним , 05-Мрт-12 11:03 
> Не удивительно. Философия питона их учит только одной религии и призывает быть
> линейным, однозначным, услужливым и послушным мальчиком :).

Ну в общем дешевым взаимозаменимым корпоративным ботом, по цене рубль за пачку.


" утилиты Grep 2.11"
Отправлено vle , 05-Мрт-12 12:49 
> PS: TIMTOWTDI, man !

Именно поэтому perl и сдох. Туда ему и дорога :-P


" утилиты Grep 2.11"
Отправлено Michael Shigorin , 05-Мрт-12 13:25 
>> PS: TIMTOWTDI, man !
> Именно поэтому perl и сдох. Туда ему и дорога :-P

Странная логика для "маргинальщика". :-]


" утилиты Grep 2.11"
Отправлено vle , 05-Мрт-12 13:54 
>>> PS: TIMTOWTDI, man !
>> Именно поэтому perl и сдох. Туда ему и дорога :-P
> Странная логика для "маргинальщика". :-]

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


" утилиты Grep 2.11"
Отправлено Аноним , 05-Мрт-12 15:26 
>TIMTOWTDI внутри *одного* ЯП приводит только к разнузданности

и нарушению дисциплины.

Из вас получится хороший винтик в обычной корпоративной машине. Остальным: TIMTOWTDI внутри одного ЯП обеспечивает возможности выбора. Вам, кстати, роднее среда с возможностью выбора или без оной (когда за вас все уже решили/навязали) ? Впрочем, если вам надо без возможности выбора (возможно зря я прошлое предложение написал), то не отвечайте вовсе - я за вас решу сам.


" утилиты Grep 2.11"
Отправлено vle , 05-Мрт-12 15:37 
> Остальным: TIMTOWTDI внутри одного ЯП обеспечивает
> возможности выбора. Вам, кстати, роднее среда с возможностью
> выбора или без оной (когда за вас все уже решили/навязали) ?

Массовый отказ от перла с приходом новых языков произошел
по вполне объективным причинам. Предлагаю на досуге о них задуматься.
Раз уж Вам так нравится выбор, я не буду навязывать свое видение...

Но TIMTOWTDI -- причина всего остального.


" утилиты Grep 2.11"
Отправлено Аноним , 05-Мрт-12 17:50 
>Массовый отказ от перла с приходом новых языков произошел по вполне объективным причинам

Произошел по одной причине, по которой скоро будет отказ от PHP в пользу ECMAScript, а потом отказ от ECMAScript. Причина проста: начинающие (!) программисты думают что всегда проще написать свою реализацию Linux Kernel чем разобраться в существующем коде. А если учесть, что к массовому наплыву быдлокодеров и быдлопользователей в интернеты уже был приличный объем кода и разнокалиберных библиотек и готовых решении на Perl, то вполне логично что вместо того чтобы разбираться с существующим (а это сложно) - быдлокодеры ушли в PHP, где начали обильно плодить быдлокод. А сейчас придет новое поколение, которому надо кушать и самый легкий путь - вытеснять PHP (ниша заполнена) в пользу JScript. Корпорации это тем более на руку, т.к. нанять "зеленого" студента сцеплять классы на JScript за 2 рубля куда выгоднее чем нанимать уже опытного PHP'шника (который себе уже цену знает). А что мне сказать про perl-программиста который осилил TIMTOWTDI не только относительно синтаксиса, но и относительно техник построения сложных систем (да-да, есть несколько(!) распространенных моделей построения) ?


" утилиты Grep 2.11"
Отправлено Wulf , 05-Мрт-12 16:26 
> TIMTOWTDI внутри одного ЯП обеспечивает возможности выбора.

К сожалению, в перле TIMTOWTDI относится скорее к синтаксису, нежели чем к семантике. Гораздо лучше, чтобы было наоборот


" утилиты Grep 2.11"
Отправлено Аноним , 05-Мрт-12 17:40 
TIMTOWTDI относится не только к синтаксису, но и к семантике. Стоит ли мне говорить что Perl не навязывает определенный стиль программирования как и Си. И стоит ли мне указывать пальцем на людей которые рефлексируют на синтаксис perl из-за TIMTOWTDI ? И, скажите мне пожалуйста, как вы осиливаете код проектов на Си где все обильно обложено макросами и язык легко позволяет это делать (чем не TIMTOWTDI ?). Вот сколько не говорите - но я вас, неосиляторов, синтаксиса perl непонимаю. Что, у вас на самом деле возникают сложности с синтаксисом языка? Ну а сложности конструируемой системы, по-видимому, за вас уже инкапсулировали в классы и вы об этом никогда не знаете, так?

" scoping"
Отправлено Michael Shigorin , 05-Мрт-12 16:38 
> TIMTOWTDI внутри *одного* ЯП приводит только к разнузданности и нарушению дисциплины.
> Моя маргинальщина нелюбви к перлу не противоречит.

На рхел внутри одного POSIX -- шагом-арш!

(привет от другого "маргинальщика", ага :)


" утилиты Grep 2.11"
Отправлено Аноним , 05-Мрт-12 15:19 
Perl сдох как сдох Linux? Пиши как есть: перл сдох среди быдлокодеров. Сейчас perl-сообщество ушло в тень. Вцелом же, скажу что за последние неск. лет есть положительный тренд в разработке perl'а и его модулей. Если не вершишь - можешь сам рассчитать график stabel и dev релизов перла.

" утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 23:01 
> Все мы осилили (может и не в полной мере), но perl универсальнее
> чем каждая из утилит отдельно.

Но утилиты всегда есть - а перловку ещё ставить придётся.


"...утилиты..."
Отправлено Michael Shigorin , 05-Мрт-12 13:26 
> Но утилиты всегда есть - а перловку ещё ставить придётся.

Перловку в большинстве виденных случаев просто так не снесёшь.


" утилиты Grep 2.11"
Отправлено zerot , 03-Мрт-12 23:01 
как не гадко поддерживать анонима ... перл это вещь, также пользуюсь регулярно. но ни один из моих коллег по нескольким крупным конторам не осилил, по причине чего пришлось и мне для унификации по возможности решать через sed|awk|grep|cut etc...
-
справедливости ради перл как инструмент для обработки строк в тыщу раз универсальнее, удобнее и логичнее шеловских костылей, но на небольших задачах можно обойтись и ими. ну и да, один и тот же скрипт на костылях шела может напороться на разные ключи костылей в Linux, AIX и солярке ...
_
ИМХО

" утилиты Grep 2.11"
Отправлено Pisto , 04-Мрт-12 18:07 
> напороться на разные ключи костылей в Linux, AIX и солярке

Есть вполне определенные стандарты для переносимого скриптинга на шелл.


"Новая версия утилиты Grep 2.11"
Отправлено Антон , 03-Мрт-12 11:51 
cmd | perl6 -e '...'
Попробуй так, бро. Так перспективнее.

"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 11:58 
>Так перспективнее.

Не думаю. Мода на ООП головного мозга проходит. Perl (5) много ближе к Си чем 6й. Ну а полезные фичи 6ого портируются в 5й. Так что ..


"Новая версия утилиты Grep 2.11"
Отправлено Антон , 03-Мрт-12 12:40 
мда, я знал что стоит поставить тег "сарказм"

"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 12:42 
Ты прав. Лично я сарказма как-то не увидел.

"Новая версия утилиты Grep 2.11"
Отправлено XoRe , 03-Мрт-12 14:26 
> хорошая и нужная тулза для скриптов, но  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 2.11"
Отправлено Аноним , 03-Мрт-12 15:01 
>Откройте для себя grep -P

Откройте для себя сообщение #9. Никакое сочетание из множества [ivGFEPf] не дает возможность быстро и безболезненно запрограммировать сложные логики. Grep годится только под простые задачи уровня линейной фильтрации - не более.


"Новая версия утилиты Grep 2.11"
Отправлено ram_scan , 03-Мрт-12 15:17 
Похоже вы и без goto тоже программу написать не умеете.

Для одноразового костыля вне зависимости от его поморочености всегда хватало bash+sed+awk+grep. Во всяком случае я на этом деле ожнажды сделал парсер детализаций телефонн6ых звонков, их нарезку на куски и последующую рассылку по списку пациентам (для чего рожал письма с аттачами и сопроводительным текстом), пока программеры в биллинге это дело фиксили. А да, команда sendmail мне понадобилась еще. Для рассылки.

Unix way. Работы заняло на два часа вместе с отладкой. Мог бы написать на перле, но лениво было трахаться.


"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 17:14 
>Похоже вы и без goto тоже программу написать не умеете.

Вы ошиблись. Скорее вы делаете скоропостижные выводы руководствуясь поверхностными суждениями.

>Для одноразового костыля вне зависимости от его поморочености всегда хватало bash+sed+awk+grep. Во всяком случае я на этом деле ожнажды сделал парсер детализаций телефонн6ых звонков, их нарезку на куски и последующую рассылку по списку пациентам (для чего рожал письма с аттачами и сопроводительным текстом), пока программеры в биллинге это дело фиксили. А да, команда sendmail мне понадобилась еще. Для рассылки.

Одноразовые костыли навроде нарезки линейно-отфильтрованного текста я тоже делаю с использованем grep, split, .. (по надобности). Ну а если текст требует сложного фильтра и/или еще и обработки части текста то тут уже только perl (можно конечно на чем угодно - хоть на tcsh, но на perl получается почему-то быстрее, лаконичнее и проще).


"Новая версия утилиты Grep 2.11"
Отправлено zomg , 03-Мрт-12 19:44 
split и cut попутали.

"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 21:16 
Очередной с поспешными выводами: во-первых, вы не разглядели многоточие и, во-вторых, откройте для себя опции к split.

"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 23:10 
>Grep годится только под простые задачи уровня линейной фильтрации - не более.

А что в man grep утверждается то то обратное?
Парень ты серьёзно болен.



"Новая версия утилиты Grep 2.11"
Отправлено евлампий , 04-Мрт-12 08:45 
> Откройте для себя сообщение #9. Никакое сочетание из множества [ivGFEPf] не дает
> возможность быстро и безболезненно запрограммировать сложные логики. Grep годится только
> под простые задачи уровня линейной фильтрации - не более.

А Вы для себя команду М-х grep в Емаксе не открывали? Преудобнейшая штуковина, доложу Вам.
А perl -- он конечно хорош и силен. Сам для сравнительно простых  вещей обхожусь bash|awk|sed|grep|tr|cut..find да же perl -e '' (также на участках текста в емаксе M-1-M-|). Но и сбацать на awk-grep-sed в этом случае намного проще (а find в перле не хватает )
И да,  perl -- является часто является зависимым пакетом на Лине (даже на фряхе).    
В общем, все они друг друга дополняют.  


"Новая версия утилиты Grep 2.11"
Отправлено евлампий , 04-Мрт-12 08:55 
К сказанному:
>  вещей обхожусь bash|awk|sed|grep|tr|cut..find

еще head и особенно tail хороши, sort...


"Новая версия утилиты Grep 2.11"
Отправлено Stax , 03-Мрт-12 18:24 
Только вот perl -e намного тормознее grep на простом поиске. И это не какая-то абстракция - это реально заметно, разница в несколько раз по скорости между grep'ом и другими искалками. Например, очень часто grep находит моментально, открываешь в less, ищещь - и ждеееешь.

А причина проста - http://swtch.com/~rsc/regexp/regexp1.html


"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 18:42 
Это очень полезная статья. Надо будет perl-сообществу показать ее, только сначала разобраться в этом.

"Новая версия утилиты Grep 2.11"
Отправлено vle , 05-Мрт-12 12:54 
> перловые регехпы - самые гибкие а не самые быстрые.

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


"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 06-Мрт-12 04:29 
сравните результаты

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}

перл только грепу и проигрывает, и то - не фатально.
и это с учетом того, что в одиночку греп - пустое место.


"Новая версия утилиты Grep 2.11"
Отправлено vle , 06-Мрт-12 12:39 
> сравните результаты
> 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


"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 06-Мрт-12 17:28 
> В подавляющем большинстве случаев "гибкость" перловых регекспов,
> которая приводит к неизбежной экспоненте в трудоемкости, не нужна.

я вам дал простой "негибкий" пример, который не приводит к экспоненте ни в трудоемкости ни в ресурсоемкости. в нем перл обгоняет GNU awk и GNU sed.
чем вы опять недовольны?

вот еще бенчмарк до кучи.
http://lh3lh3.users.sourceforge.net/reb.shtml


"Новая версия утилиты Grep 2.11"
Отправлено vle , 06-Мрт-12 19:18 
> я вам дал простой "негибкий" пример, который не приводит к экспоненте ни
> в трудоемкости ни в ресурсоемкости.

Статьи, надо понимать, не прочитаны.
Ясно, разговор этот бесполезен.
Хотя, если нет понимания того, что такое
"трудоемкость алгоритма", на что можно было надеяться...

> в нем перл обгоняет GNU awk и GNU sed.
> чем вы опять недовольны?

Тупым упрямством собеседника.
Мне мало интересны бенчмарки на регекспах в 10 символов.

> вот еще бенчмарк до кучи.
> http://lh3lh3.users.sourceforge.net/reb.shtml

Читаешь книгу, а видишь фигу.
Сравни цифры в _последней_ колонке и строках
с пометкой BT и FSA.


"Новая версия утилиты Grep 2.11"
Отправлено Michael Shigorin , 06-Мрт-12 18:07 
> сравните результаты

Забыли сперва всё 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...

> и проигрывает, и то - не фатально.

Угу, в два с половиной раза по ходикам на стенке при предложенных Вами условиях на ноуте под руками.

Хотя осмысленно было бы сделать серию забегов на различных массивах данных, чтобы разделить время инициализации и время собственно работы.

> и это с учетом того, что в одиночку греп - пустое место.

Для данной задачи греп как раз минимально непустое место, бишь оптимальное.  При всём моём уважении к перлу.


"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 06-Мрт-12 19:49 
>> сравните результаты
> Забыли сперва всё 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-7

Linux 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

т.е., как кто-то заметил выше, приходится менять инструмент

перл как минимум умеет все, что умеют вышеперечисленные тулзы, так что когда нужно сделать более менее сложную выборку, лично я начинаю именно с перла


"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 06-Мрт-12 19:55 

> для данной задачи - лучше перла я бы и сам ничего не
> придумал

грепа, разумеется, пардон :)


"Новая версия утилиты Grep 2.11"
Отправлено Michael Shigorin , 07-Мрт-12 02:45 
>>> сравните результаты
>> Забыли сперва всё 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 ...

Зависит.  Наблюдал, как некоторые штуки переписывали с перла как раз на поток.

> перл как минимум умеет все, что умеют вышеперечисленные тулзы

|


"Новая версия утилиты Grep 2.11"
Отправлено Andrey Mitrofanov , 07-Мрт-12 12:00 
> сравните результаты
> 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 ...' , чтоб значащих цифр поболе.


"Новая версия утилиты Grep 2.11"
Отправлено arisu , 06-Мрт-12 05:33 
> Это очень полезная статья. Надо будет perl-сообществу показать ее, только сначала разобраться
> в этом.

перл-сообщество в курсе, ему пофигу.


"Новая версия утилиты Grep 2.11"
Отправлено Kodir , 05-Мрт-12 12:49 
Поддерживаю перловый тулз. Современные потребности уже намного больше, чем 'grep error'.

"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 03-Мрт-12 15:33 
теперь что для каждой утилиты которой добавилась еще одна опция и исправлиил 1 баг будем рисовать новость?

"Новая версия утилиты Grep 2.11"
Отправлено Andrey Mitrofanov , 06-Мрт-12 09:24 
Да, чё там, стирай.</деревянное>

"Новая версия утилиты Grep 2.11"
Отправлено Аноним , 05-Мрт-12 10:11 
> размер которой не укладывается в тип INT (2 Гб (!) для 64-разрядных систем).

что, простите?


"Новая версия утилиты Grep 2.11"
Отправлено Andrey Mitrofanov , 05-Мрт-12 10:56 
>> размер которой не укладывается в тип 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.