https://www.opennet.me/openforum/vsluhforumID3/79621.html Представлен (http://www.linux.com/learn/tutorials/480530:is-glark-a-better-grep) проект Glark (http://www.incava.org/projects/glark), в рамках которого создана утилита, претендующая на роль улучшенной альтернативы grep. Код Glark написан на языке Ruby.<br><br><br>Отличительные черты Glark:<br><br><br><br>- Подсветка масок и имен файлов в выводе;<br>- Использование perl-совместимых регулярных выражений (PCRE (http://www.pcre.org)), привычных для разработчиков на языках Perl, PHP, Python и Ruby;<br>- Возможность использования составных выражений, работающих с учетом содержимого нескольких строк. Например: "glark --and=5 --or cout print --or double float *.c" выполнит поиск ключей "cout" или "printf" в ближайших 5 строках от строк с ключами "double" или "float";<br>- Автоматическое определение тестовых файлов (поиск в бинарных файлах не производится;<br>- Режим совместимости с GNU grep;<br>- Поддержка указания диапазонов. Указание опций "--before" и "--after" позволяет ограничить область поиска, отсеяв опред...<br><br>URL: http://www.lin https://www.opennet.me/openforum/vsluhforumID3/79621.html#69 Thu, 11 Aug 2011 14:04:09 GMT Не знаю как щас а ack пару лет назад был глюкодромом: он выводил не всё. Не знаю как авторы добились. Плюс утилита стрёмная - её код автосгенерирован.<br> https://www.opennet.me/openforum/vsluhforumID3/79621.html#68 Thu, 11 Aug 2011 12:04:25 GMT "каждая программа должна заниматься своим делом"<br><br>Это unix-way. Не все его понимают. Смиритесь )<br> https://www.opennet.me/openforum/vsluhforumID3/79621.html#67 Thu, 11 Aug 2011 11:59:10 GMT Это можно было бы хотя бы поставить поиграться и поржать. Такие бредовые проэкты периодически возникают. Вроде quake в псевдографике ) В чём fun тут непонятно. Недостатка юзабельности grep за мой стаж общения с linux не замечено.<br> https://www.opennet.me/openforum/vsluhforumID3/79621.html#66 Thu, 11 Aug 2011 11:20:00 GMT Альтернативон одарённая альтернатива! ---"Нежнее, Владимир."<br> https://www.opennet.me/openforum/vsluhforumID3/79621.html#64 Thu, 11 Aug 2011 05:36:44 GMT для того, чтобы скипать часть файла есть tail и head, накойхрен это в утилиту поиска вструмлять? каждая программа должна заниматься своим делом, но хорошо. а для чуть более сложных - можно уже и awk с perl использовать. <br> https://www.opennet.me/openforum/vsluhforumID3/79621.html#63 Thu, 11 Aug 2011 05:03:35 GMT &gt; Спасибо, интересная библиотека, приму на заметку :) <br><br>на здоровье. использую много лет, очень доволен, стррррашных багов не видел. жаль, что все знают про pcre, и почти никто &#8212; про tre. по мере сил способствую, так сказать.<br> https://www.opennet.me/openforum/vsluhforumID3/79621.html#62 Thu, 11 Aug 2011 04:58:07 GMT Спасибо, интересная библиотека, приму на заметку :)<br> https://www.opennet.me/openforum/vsluhforumID3/79621.html#60 Wed, 10 Aug 2011 23:17:40 GMT (задумчиво) а вот у офигенной библиотеки tre в составе идёт agrep. мало того, что сама tre очень шустра (да-да, то самое, что выше в ссылках &#8212; fallback только для бэктрэкинга), так оно ещё умеет &#171;приблизительные регэкспы&#187; (то бишь, регэкспы с указаным диапазоном несовпадения). и написано на сях, потому маленькое и шустрое.<br><br>вопрос: этот рубикомбайн (который руби за сабой тянет) &#8212; умеет &#171;приблизительные регэкспы&#187; хотя бы? или скорость, как у agrep?<br><br>вопрос риторический, если что.<br> https://www.opennet.me/openforum/vsluhforumID3/79621.html#59 Wed, 10 Aug 2011 22:27:43 GMT &gt; В ChromeOS так и есть я полагаю. :) <br><br>Там на яве мыслить полагается наверное. Ну или хотя-бы на яваскрипте.<br><br>