Представлен (http://www.linux.com/learn/tutorials/480530:is-glark-a-bette...) проект Glark (http://www.incava.org/projects/glark), в рамках которого создана утилита, претендующая на роль улучшенной альтернативы grep. Код Glark написан на языке Ruby.
Отличительные черты Glark:- Подсветка масок и имен файлов в выводе;
- Использование perl-совместимых регулярных выражений (PCRE (http://www.pcre.org)), привычных для разработчиков на языках Perl, PHP, Python и Ruby;
- Возможность использования составных выражений, работающих с учетом содержимого нескольких строк. Например: "glark --and=5 --or cout print --or double float *.c" выполнит поиск ключей "cout" или "printf" в ближайших 5 строках от строк с ключами "double" или "float";
- Автоматическое определение тестовых файлов (поиск в бинарных файлах не производится;
- Режим совместимости с GNU grep;
- Поддержка указания диапазонов. Указание опций "--before" и "--after" позволяет ограничить область поиска, отсеяв опред...URL: http://www.linux.com/learn/tutorials/480530:is-glark-a-bette...
Новость: http://www.opennet.ru/opennews/art.shtml?num=31446
+6 к фичам, -10 к скорости, -100 к размеру (руби же в зависимостях)
+ 100 к размеру, вы хотели сказать?
да
Алсо:
+1 к скиллу кодинга в руби
-10 к скиллу разумного решения инжеерных задач.
а я почему-то думал, что главное в этой утилите - скорость...
> а я почему-то думал, что главное в этой утилите - скорость...поддерживаю
> а я почему-то думал, что главное в этой утилите - скорость...Мне почему-то фич оригинального грепа хватает выще крыши, а вот идея еще и руби качать для работы с оным да потом еще за версией оного следить меня что-то совсем не прельщает.
> руби качать для работы с онымRuby — зависимость texlive, его не надо качать.
> Ruby — зависимость texlive, его не надо качать.У меня почему-то нет никакого texlive и руби, но греп есть.
Нет. (C)grep(1) никогда за скорость не боролась. Хотите быстро искать подстроку -- используйте fgrep(1).
+скорость
-regexpБыстро, дёшево, качественно -- любые два на выбор.
Так то оно так ... Но вот даже не запуская этот тулз готов на деньги поспорить что "медленному" grep'у он сольёт :) Напрочь!(С)Анек
Уберите из особенностей то, что есть в GNU grep или отделите их как-то
Подсветка есть (--color для цвета, -H для отоборажения имени файла, -n номера строк)
Диапозоны есть (-A -B -C)
и вообще man grep сначала
Мне эта какашка на руби не нужна. Пусть на си перепишут. :)
> улучшенной альтернативы grep.
> Код Glark написан на языке Ruby.не клеится как-то
чем оно лучше ack? (http://betterthangrep.com/)
Не знаю как щас а ack пару лет назад был глюкодромом: он выводил не всё. Не знаю как авторы добились. Плюс утилита стрёмная - её код автосгенерирован.
Кому это надо? Мало того что PRCE сами по себе медленные из-за того что разработчики разменяли фичи на скорость. (Самая быстрая реализация регэкспов основана на теории конечных автоматов и конструкции Томсона.)
Так эти велосипедисты решили ещё замедлить всё это дело, переписав греп на руби... сразу закопать!
> Так эти велосипедисты решили ещё замедлить всё это дело, переписав греп на
> руби... сразу закoпать!Ну это вы понимаете, а рубисты понимают что "если на руби - значит улучшенная альтернатива". Логика забавная, но почему-то у питонистов, рубистов и жабистов это такой вот синдром.
Ребята, куда вам эта скорость? Да, иногда она необходима. Терабайты логов, бла-бла-бла. Да и то, узкое место в этом случае - ввод/вывод, на чем написана утилита - какбы не самое важное.
В большинстве же случаев удобство пользования куда приятнее. И тут свистелки вроде раскраски и PCRE как раз кстати.Хотя, по-моему тоже неочень получилось. Диапазоны бесполезны из-за head/tail, фич маловато, да и grep сам по себе неплох. Лучше бы find с человеческим лицом сделали.
grep быстр. Реализации регэкспов основанные на backtracking'е дохнут далеко не от гигабайтов логов, а от некоторых вариватов выражений, при том не очень длинных. (в статейке, что я привёл пример)
Если нужны фичи, то опять таки, всё за исключением 'backreferences' есть к примеру тут:
http://code.google.com/p/re2/"Unlike most automata-based engines, RE2 implements almost all the common Perl and PCRE features and syntactic sugars. It also finds the leftmost-first match, the same match that Perl would, and can return submatch information. The one significant exception is that RE2 drops support for backreferences¹ and generalized zero-width assertions, because they cannot be implemented efficiently. The syntax page gives full details."
> Ребята, куда вам эта скорость?Ржевский, молчать! Вот когда сам грепнешь пару гигов логов сервака - тогда и поймешь куда она нам :E.
> Да, иногда она необходима. Терабайты логов, бла-бла-бла. Да и то, узкое место в
> этом случае - ввод/вывод, на чем написана утилита - какбы не самое важное.Ввод-вывод на хороших носителях может выдавать сотни мегов в секунду. Это ваше кульное руби да еще с PCRE на раз заткнется прожевать даже скромные 100Мб/сек с стандартного сатащного диска.
> В большинстве же случаев удобство пользования куда приятнее. И тут свистелки вроде
> раскраски и PCRE как раз кстати.Не знаю кому там кстати, но мне возможностей стандартного грепа хватало, перспективу писать регэкспы я в гробу видал. И, ВНЕЗАПНО, у меня почему-то греп и без велосипедистов уже и так умеет раскраску.
> Хотя, по-моему тоже неочень получилось. Диапазоны бесполезны из-за head/tail,
> фич маловато, да и grep сам по себе неплох. Лучше бы find с человеческим лицом сделали.Зачем нужно прикручивать человеческое лицо к find? Чтобы детей им пугать? oO Велосипедисты и так справляются с пуганием, даже без человеческих рож прикрученных к утилитам.
> Ребята, куда вам эта скорость? Да, иногда она необходима. Терабайты логов, бла-бла-бла. Да и то, узкое место в этом случае - ввод/вывод, на чем написана утилита - какбы не самое важное.Наглая, тупая ложь. Скорость необходима всегда, а это угрёбище на ruby неспособно обрабатывать поток со скоростью диска, не говоря уже о ssd, рейдах, потоке из 10Gb сети, огромном выводе программы или банальном gunzip < log.gz | grep
Кроме того, иногда необходимо запустить grep много раз, а тут важна скорость запуска, которая у этого угрёбища тоже кошмарная.
Как-то не впечатляет :(> Подсветка масок и имен файлов в выводе;
grep --color
> Использование perl-совместимых регулярных выражений (PCRE), привычных для разработчиков на языках Perl, PHP, Python и Ruby;
grep -P ? Хотя experimental.
> Возможность использования составных выражений, работающих с учетом содержимого нескольких строк. Например: "glark --and=5 --or cout print --or double float *.c" выполнит поиск ключей "cout" или "printf" в ближайших 5 строках от строк с ключами "double" или "float";
Вот тут наверное всё же лучше юзать awk - язык по-богаче будет для подобных выкрутасов.
> Автоматическое определение тестовых файлов (поиск в бинарных файлах не производится;
Софт не должен об этом думать. Если не нужны бинарные файлы - не грепайте. Если не хочется долго ждать завершения поиска в длинных строках по хитрым регекспам - юзать rlimit.
> Поддержка указания диапазонов. Указание опций "--before" и "--after" позволяет ограничить область поиска, отсеяв определенную часть файла (например, для игнорирования первых 20 строк с заголовком "glark --after 20 маска файл").
Чем head/tail не угодил?
ИМХО конечно, но утилиты уровня grep должны быть быстрые и максимально простые. Руби существует не для таких вещей.
> Вот тут наверное всё же лучше юзать awk - язык по-богаче будет для подобных выкрутасов.Самое интересное, что это и побыстрее будет, а не только побогаче =)
А в чем, собственно, проблем с грепом?
> А в чем, собственно, проблем с грепом?Он написан не на руби. Поэтому у некоторых на заднице вылез красный прыщ - у них зуд, заставляющий заниматься велосипедостроением. Вообще, не жирно ли о каждом скриптике по новости зафигачивать? А если я шелскрипт на 5 строк рожу - это будет темой для новости? Может я даже какую системную утиль заменю. Ну вот например я могу на раз заменить /bin/false на версию написанную на баш (питоне, руби, перле, похапэ, яваскрипте или чем там еще). Давайте по этому поводу новость напишем? А лучше по новости на каждый язык, чтобы уж совсем хорошо :)
Подозреваю, что парни кодили исключительно ради удовольствия (как и многие другие), и от них глупо ждать чего-то полезного, они не ради этого стараются. А вот насчет того, зачем такие новости постить - тут я согласен
Ужасно. Если тут и есть здравые идеи, то это только использование pcre вместо убогих posix'овых регулярок, хотя ещё лучше было бы заюзать Яндексовские pire, бо они в разы быстрее, а все фичи pcre почти никогда не нужны.
Ух, ты!!! Теперь ждём альтернативу ed на QT?
Что ж, JustForFun...
Кстати, а почему бы не сделать 3-х мерное выделение найденных слов? С музыкальным сопровождением?
да, кстати, было бы круто. И с возможностью постить найденное сразу в фейсбук или вконтакт
Это можно было бы хотя бы поставить поиграться и поржать. Такие бредовые проэкты периодически возникают. Вроде quake в псевдографике ) В чём fun тут непонятно. Недостатка юзабельности grep за мой стаж общения с linux не замечено.
У Microsoft есть альтернатива grep-у ещё с 3-й версии DOS. Называется find.
Альтернатива - это нечто, сравнимое по функциональности, чего про мсовский файнд не скажешь
Какая ОС — такая и альтернатива. Потоковые утилиты в однозадачной системе — то ещё издевательство.
> У Microsoft есть альтернатива grep-у ещё с 3-й версии DOS. Называется find.Уточним, это не альтернатива а жалкая пародия.
Альтернативон одарённая альтернатива! ---"Нежнее, Владимир."
Цвет - alias grep='grep --color=yes'
Возможность использования составных выражений -egrep
Предлагаю написать новый grep на mono, чтобы работал только через браузер, а потом всего лишь парсить результат по скриншоту в браузере, и вставлять этот grep в обязательном порядке во все дистрибутивы.
В ChromeOS так и есть я полагаю. :)
> В ChromeOS так и есть я полагаю. :)Там на яве мыслить полагается наверное. Ну или хотя-бы на яваскрипте.
(задумчиво) а вот у офигенной библиотеки tre в составе идёт agrep. мало того, что сама tre очень шустра (да-да, то самое, что выше в ссылках — fallback только для бэктрэкинга), так оно ещё умеет «приблизительные регэкспы» (то бишь, регэкспы с указаным диапазоном несовпадения). и написано на сях, потому маленькое и шустрое.вопрос: этот рубикомбайн (который руби за сабой тянет) — умеет «приблизительные регэкспы» хотя бы? или скорость, как у agrep?
вопрос риторический, если что.
Спасибо, интересная библиотека, приму на заметку :)
> Спасибо, интересная библиотека, приму на заметку :)на здоровье. использую много лет, очень доволен, стррррашных багов не видел. жаль, что все знают про pcre, и почти никто — про tre. по мере сил способствую, так сказать.
для того, чтобы скипать часть файла есть tail и head, накойхрен это в утилиту поиска вструмлять? каждая программа должна заниматься своим делом, но хорошо. а для чуть более сложных - можно уже и awk с perl использовать.
"каждая программа должна заниматься своим делом"Это unix-way. Не все его понимают. Смиритесь )