Представлен выпуск утилиты для организации поиска данных в текстовых файлах - GNU Grep 3.4. В новой версии добавлена опция "--no-ignore-case", отключающая действие настроек отмены учёта регистра символов (-i, --ignore-case). Исключено попадание под маску "." некорректных последовательностей UTF-8. При выполнении "grep -Fw" решены проблемы с ложным сопоставлением данных в многобайтовых локалях, отличных от UTF-8. Устранены провалы в производительности при обработке большого числа шаблонов без обратных ссылок, а также шаблонов вида '01.2', приводящих к выполнению внутренней пересортировки токенов...Подробнее: https://www.opennet.me/opennews/art.shtml?num=52128
Не нужно. ripgrep в 3.5 быстрее.
А нам некуда спешить: тише едешь -- дальше будешь. А то грепают тута аки самолёты, нет чтобы остановиться и оглянуться куда летят-то. Кто-то ведь в пропасть летит. Но нет, летят, бегут куда-то. Зачем? Эх-х-х...
иногда надо по-быстрому в многометровом логе найти нужное событие...
многогиговом
> многогиговомТакие логи есть смысл сваливать в более специальные системы с индексированием, если поиск по ним является сколь-нибудь частой задачей.
Например, вот человек несколько лет назад описал свою "замену Splunk на открытом софте": http://edgeofsanity.net/article/2012/06/17/central-logging-w...
Имхо, пока ничего лучше sawmill не придумали для этой задачи, но... даже sawmill как-то не может эффективно в 16-32 треда и в сотню гигов памяти. Да, логи скорее малотеровые, чем многогиговые....
Главное настроить систему логирования на системе логирования, что бы когда она будет падать определить причину.
дороговато для грепа
Тогда греп надо на электрон переписать.
не успеюют - быстрее сделают grepd
Да, rg и fd - должны быть на каждой системе. Fd кстати сделан поверх либы walkdir, которую тоже BurntSushi написал. Великий человек.
riggrep написан на rust, не учитывает особенности unicode (u(ss)->ß) и не портируем на некоторые современные и безопасные архитектуры.
Объясни по-подробнее про особенности utf8, что не так?
Я не знаю, что он имел в виду, но венда тоже не умеет в utf8. По-моему я даже в бсод ронял 10 и кучу програм в ней всего 1 символом (совершенно валидным в линуксе), не знаю, починили ли с тех пор. Так что особенности есть.
https://snipboard.io/5E9mRX.jpg
> https://snipboard.io/5E9mRX.jpgТам свой особенный утф8, мало общего имеющий со стандартом. Дело не в том, что он не отображается, а в том, что юникод в венде будет совершенно свой (и если использовать его, проблемы будут у других систем), а часть символов и вовсе вызовет бсод и инстакраши софта (передаю привет notepad++). В линуксах не крашится.
А что за символы с которыми крешится или которые несовместимы? Прям сейчас бы опробовал на винде и линуксе.
> А что за символы с которыми крешится или которые несовместимы? Прям сейчас
> бы опробовал на винде и линуксе.Я не помню, какие именно, но даже в википедии емнип было написано (в японской [1] так точно). Ну вот к примеру описываемые мной различия у вендоров [2].
[1] https://ja.wikipedia.org/wiki/Unicode
[2] https://web.archive.org/web/20110422181018/http://www.ingrid...
UTF-8 не нужен при наличии полноценного юникода. Квест "угадай сколько байтов потянет каждый символ длинной-предлинной строчки если в ней гарантированно не только латиница" сильно на любителя.
> UTF-8 не нужен при наличии полноценного юникода. Квест "угадай сколько байтов потянет
> каждый символ длинной-предлинной строчки если в ней гарантированно не только латиница"
> сильно на любителя.Полноценный - это какой? UTF-32? Ну да, там есть небольшой запас, чтобы на это забить и считать 4 байта примерно равно 1 символ (и то с оговорками вроде модифицирующих кодпоинтов). Только ведь он жутко неэффективный в части занимаемой памяти, правда?
> Полноценный - это какой? UTF-32?В винде вроде двухбайтовый UCS2 фигурировал...
PS: "полноценный", ага.
В UTF-8 в теории символ может до 6 байт весить, это сильно лучше или как?
> В UTF-8 в теории символ может до 6 байт весить, это сильно
> лучше или как?Очень в теории, текущий лимит 4 байта из соображений совместимости. И всяко лучше utf-16. [1] %)
По-моему, на практике 4 довольно редко встречалось и только в китайских текстах. Но это совершенно не важно, случайный доступ с юникодом просто не применяют.
> riggrep написан на rust, не учитывает особенности unicode (u(ss)->ß)Угу, то ли дело греп, на который еще не так давно (лет 6 назад) любители вставить "ß" затейливо матюкались из-за принципиальных проблем поиска с умляутами.
% echo "THISS"|grep -ic "ß"
0% echo "straße"|grep -ic "ss"
0% grep --version
grep (GNU grep) 3.3
В спеке на утф-8 сказано, что Eszett приравнивается к "ss"? Я такого найти не смог, более того на стековерфлоу сами немцы говорят, что с точки зрения языка Eszett *не равен* "ss", плюс у них вокруг этого переодически правила меняются. Также интересно - какое дело до обработки этого символа юзеру опеннета? Товарищ парсит в консоли немецкие логи?
> В спеке на утф-8 сказано, что Eszett приравнивается к "ss"?Мне лень смотреть. Ведь это не я писал о том, что ripgrep "не учитывает особенности unicode (u(ss)->ß)".
Проще было проверить на практике – grep тоже как-то не очень учитывает (утф-8 используется по умолчанию)> найти не смог, более того на стековерфлоу сами немцы говорят, что с точки зрения языка Eszett *не равен* "ss", плюс у них вокруг этого переодически правила меняются.
Конечно не равен – вы не можете заменить любую двойную "ss" на ß.
А вот наоборот - (грубо говоря) всегда. Даже в деловой переписке это не будет чем-то уж слишком "из ряда вон".Но да, стековерфлоу – это конечно авторитет! Куда тем же "Дойче Правописание [Правила]" (§25) до мнения авторитетов 🙄
https://www.rechtschreibrat.com/DOX/rfdr_Regeln_2016_redigie...
https://www.duden.de/sprachwissen/rechtschreibregeln/doppel-...
> E2: Steht der Buchstabe ß nicht zur Verfügung, so schreibt man ss. In der Schweiz kann man immer ss schreiben. Beispiel: Straße – Strasse
> Если нет буквы ß - пишем ss. В Швейцарии вообще можно всегда писать ss вместо ß..
> E3: Bei Schreibung mit Großbuchstaben schreibt man SS. Daneben ist auch die Verwendung des Großbuchstabens ẞ möglich. Beispiel: Straße – STRASSE – STRAẞE.
> Для заглавных/прописных букв используется SS. (Если в шрифте присутствует - старая формулировка до ввода "официальной" большой ß) прописная ß, то возможно написание с <большая ß>Кстати, авторитеты не затрагивали проблему поиска в старых документах, где вместо isst, dass, wusste писали ißt, daß, wußte?
Небольшая подсказка насчет новых-старых правил:
Любителям умляутов (причем, вполне серьезным и уважаемым изданиям газет и журналов) не впервой просто проигнорировать "блидинг-эдж" нововведения, вплоть до их отмены или серьезной переработки ;)
Да и благодаря таким "реформам" с отменами - до сих пор вполне нормально воспринимается старое правописание.Ну и матюкались не на то, что ß не заменялось на "ss" при поиске, а на то, что ни ß, ни поиск öäü - вообще не работал толком:
http://www.knoppixforum.de/knoppix-forum-deutsch/sonstiges/t...
https://forum.ubuntuusers.de/topic/grep-findet-keine-umlaute...
https://bbs.archlinux.org/viewtopic.php?id=96082
(длинный список по запросу поисковика "grep umlauts")
А если задаться целью - то на грабли c умляутами до сих пор и на утф8 наткнуться можно:
https://stackoverflow.com/questions/24962147/grep-and-utf-8-...
https://stackoverflow.com/questions/49535221/how-to-grep-uml...> Также интересно - какое дело до обработки этого символа юзеру опеннета? Товарищ парсит в консоли немецкие логи?
Мне лично - никакого.
Но критиковать ripgrep, тактично умалчивая о той же проблеме в grep -- немножечко отдает двойными стандартами.
> Небольшая подсказка насчет новых-старых правил:Ну вот, опять восхищаюсь Вашими тщательностью и кругозором :-)
Был бы рад знакомству.PS: а может, в 2020 опеннетовку проведём хотя бы в Москве или Питере?
>> Небольшая подсказка насчет новых-старых правил:
> Ну вот, опять восхищаюсь Вашими тщательностью и кругозором :-)Просто приходится много общаться с немецкоязычными, поэтому и разбираться с вывертами правописания приходилось особо тщательно – так что это не кругозор, а скорее "сопутствующие спец. знания" ;-)
> Был бы рад знакомству.
> PS: а может, в 2020 опеннетовку проведём хотя бы в Москве или Питере?Лет 6-7 назад вполне. Сейчас, к сожалению, то семья, то здоровье "теребят".
> переодическиПериод, а не переод.
У него беда с докой. Он понимает опции -e, -f, -l, -n, -s, -q, -v?
rg --helpДовольно подробная.
https://pastebin.com/N7xZyMnD
Я люблю Rust и юзаю rg, но вот такие провокационные комментарии мне совсем не нравятся. rg - это альтернативная молодая тула: пусть со своими шикарными преимуществами, но и со своими альтернативными недостатками. Нет ничего плохого в том, что стандартный инструмент развивается и становится лучше, потому что этот инструмент на данный момент везде.На opennet и так люто ненавидят Rust и костерят его всякими "хрустами", а такие провокации только масла в огонь подливают. Или это и была цель?
Тезис был: grep - не нужен. Если ты считаешь, что это не так, объясни - зачем нужен grep при наличии лучшей альтернативы?
Я держусь позиции, что Rust должен будет заменить C, особенно когда до конца решатся все проблемы llvm с алиасингом и Rust станет в целом быстрее, чем C. Но по банальной реакции аудитории opennet на Rust видно, что сообщество пока к этому не готово (в англоязычном сообществе примерно такая же ситуация, только без такого количества агрессии).Но на данный момент конкретно с rg я вижу такие очевидные проблемы:
1. rg не POSIX-совместим. Это не то чтобы плохо, стандарту POSIX уже сколько лет и пора бы двигаться дальше, но пока это проблема. В целом, это решаемо банальным созданием POSIX-совместимой обертки.
2. llvm пока поддерживает не так много архитектур
3. Rust пока что вызвает много недоверия у сообщества, потому шанс того, что мейнтейнеры текущих популярных дистрибутивов зареплейсят grep на rg в качестве стандартной утилиты довольно мал. Соотвественно на данный момент важно, чтобы GNU grep существовал хотя бы на аппарате жизнеобеспечения.
Греп обязательно должен быть в стандартных поставках потому, что многие скрипты его используют. Но самому пользоваться грепом не вижу смысла. Также, как и find-ом (fd сильно быстрее). Я их оба два закатал в базовый докеровский образ на котором остальные все образы на работе базируются. Очень удобно.Что касается пакетов в дистрибутивах, это вообще по-барабану - есть ripgrep в пакетах или нет. cargo install ripgrep если для личных нужд. А для рабочих есть ansible или образы для поддержания единства конфигурации машин.
В целом согласен, но все же поскольку от GNU grep пока никуда не убежишь, это хорошо, что в нем хотя бы баги латают.
> 3. Rust пока что вызвает много недоверия у сообщества, потому шанс
> того, что мейнтейнеры текущих популярных дистрибутивов зареплейсят
> grep на rg в качестве стандартной утилиты довольно мал.Я бы сказал -- тождественно равен нулю. Особенно для тех, которые заморачиваются не-x86 (и ещё и не-arm) -- там "помножить на хреновую поддержку архитектур".
>Я держусь позиции, что Rust должен будет заменить C,Рано или поздно что-то заменит C. Но почему вы уверены, что это будет Rust, а не, например, Verona или подмножество betterC языка D?
>особенно когда до конца решатся все проблемы llvm с алиасингом и Rust станет в целом быстрее, чем CА как решится проблема с запретом использования названия Rust в альтернативных реализциях? Кажется, уже кто-то наступал на подобные грабли, не Sun ли это был?
Возможно и не Rust. Не хотелось бы, чтобы Verona, едва ли ситуация с именем в таком случае будет лучше, а то может и не в одном имени проблемы будут, это же microsoft.По крайней мере, даже если с Rust что-то пойдет не так, скорее всего тот язык, который таки прочно заменит C, будет как минимум использовать многие идеи и наработки из Rust.
Просто пока у Rust больше всех шансов. К D никто интереса не проявляет, да и он на самом деле не решает такого количества проблем, как Rust, да и комбинация ооп и функционального программирования в Rust очень здорово работает, как по мне. Насколько знаю, автор D даже начал делать borrow checker для своего языка, чтобы это исправить. Может что-то из этого и выйдет. Про Better C мало слышал, чуть позже почитаю.
А конструкции типа (\[.*?\]+) более лучшая альтернатива грепать умеет? Если нет, то сами знаете, куда её запихнуть вместе с авторами, потому что это совсем не альтернатива.
Очевидно умеет, странный вопрос. И сделает это намного быстрее.
>намного быстрееПоставил, пришлось скачать 15мб (раст у меня был). Установка заняла 5 минут, экзешник 4.5 мегабайта (греп 0.2 мегабайта - отработает пока оно считается в память!).
По факту, результаты следующие.
grep(на холодную без кэшей):
real 0m0.009s
user 0m0.001s
sys 0m0.002s
rg(на холодную без кэшей):
real 0m0.038s
user 0m0.002s
sys 0m0.005s
grep(повторный запуск подряд):
real 0m0.002s
user 0m0.001s
sys 0m0.001s
rg(повторный запуск подряд):
real 0m0.004s
user 0m0.003s
sys 0m0.001s
Данных было 15 байт, система на ссд. Вывод: ваша информация - очередной фейк.
Угу, здорово. Я ведь тоже вам могу сейчас случайных чиселок набросать, но заниматься этим я, конечно, не буду, потому что это детский сад.Если бы вы действительно хотели выяснить правду, а не подтвердить для себя собственное мнение, вы бы серьезно изучили вопрос, провели бы много разных тестов и скорее всего сюда бы ничего не написали.
Вы бы циферками и ответили, а не детским садом.
Я не большой специалист в данном вопросе, чтобы анализировать эти чиселки (тем более не имея на руках тестовых данных, что делает ситуацию еще более глупой). Все, что я могу сказать - на моей машине rg работает во много раз быстрее.Обращаясь и к вам, и к остальным читающим. Не слушайте ни меня, ни господина с чиселками - поставьте rg на свою машину и протестируйте на своих реальных задачах. Было бы очень глупо, если бы вы сейчас прочтитали господина с чиселками, вам понравилось его мнение (ведь конечно, Rust ничего не может и пишут на нем глупые хипстеры), а в итоге оказаться неправым, верно?
> Все, что я могу сказать -...это детский сад, увы. Нет, я тоже чаще "меряю на глазок", чем отмеряю микрометром [и отрубаю топором], но это всё же осознавать надо.
> Обращаясь и к вам, и к остальным читающим. Не слушайте ни меня,
> ни господина с чиселками - поставьте rg на свою машинуПеречитайте, пожалуйста, #12 и подскажите, где взять rust для e2k. Моя основная рабочая машина именно на этой архитектуре.
PS: если "чиселки" не разобрали -- хотя бы отгрепав глазами(sic!) по real -- то главная из них там была 15 (та, что в последней строчке), как мне кажется. По сути это измерение скорости запуска, а для оценки самой молотилки стоило бы погонять на -F разной длины и регэксах разной заковыристости по массивам данных от единиц байт (как там) до хотя бы мегабайт. Если интересно -- ну так займитесь же, заодно можно теорию погрешностей подтянуть или вовсе открыть для себя :-)
С высоты птичьего полета, безо всякой теории погрешностей. У меня не SSD, как у господина с чиселками - у меня зашифрованный раздел на жестком диске, и на нем я наблюдаю значительную разницу. И чиселками я бросаться не буду, потому что числелки на каких-то непонятных данных, на чьей-то чужой машине со своей конфигурацией, в чем-то убеждают, мне кажется, только не слишком далеких людей.> где взять rust для e2k.
Архитектура довольно молодая, почему она уже обязана поддерживаться llvm? Прочитал, что у вас есть двоичная трансляция из x86 - можете с ней попробовать. Я не то чтобы евангелист llvm - лучше бы у Rust был свой бекенд. Но пока как есть.
>непонятных данныхА чё, можете сами проверить. Вот вам данные http://ftp.freedb.org/pub/freedb/freedb-complete-20191203.ta... и вот вам текст, который нужно извлечь во всех файлах: '(\[.*?\]+)'
Теперь если скажете, какие ключи надо скормить rg, тобы тот отработал сопоставимо с grep -RPo * (и желательно выдал те же данные в том же формате), я признаю, что раст имеет право на существование.
Вот вам более реальное тестирование. Это всё, что нужно знать о хипстоподелках и восторженных отзывах в интернете.https://www.opennet.me/openforum/vsluhforumID3/119373.html#57
> Угу, здорово. Я ведь тоже вам могу сейчас случайных чиселок набросать, но
> заниматься этим я, конечно, не буду, потому что это детский сад.
> Если бы вы действительно хотели выяснить правду, а не подтвердить для себя
> собственное мнение, вы бы серьезно изучили вопрос, провели бы много разных
> тестов и скорее всего сюда бы ничего не написали.Ну знаю, у меня не было мнения. Но я считаю, что должно быть сопоставимо с си, а не в 4 раза медленней (тем более, если речь идёт об использовании в скриптах, а не о разборе гигабайтов текста).
Пытаюсь придумать тестирование с другим тестовым набором данных (где я возьму гигабайт текста?), но пока не получается и результаты выглядят ещё хуже для противников гну.
Хорошо, реальный юзкейс. Грепнул 1.1гб текста/1100000 файлов (сущий пустяк, в принципе, во всяком случае для меня и моих данных) и чёт совсем грустно стало. В общем, прекращайте фейкомётить.
rg:
real 61m38.956s
user 0m34.536s
sys 1m1.371sgrep:
real 2m44.097s
user 0m11.746s
sys 0m24.306s
Во время работы рг потреблял 200+ мб оперативки (уже несколько дико для применения в скриптах), греп всего 30мб. А если его тысячу раз в секунду вызывать? Ведь чем больше футпринт, тем больше сайд эффектов при использовании выплывает.Зачем он спавнит кучу тредов, кстати? Ведь всё равно значительно быстрее не будет, а на случайном доступе просадки только такие. Выглядит, как типичная хипстоподелка каких-то школьников. Не то, чтобы это было плохо само по себе, но вот то, как вы о ней отзываетесь... И это будет конкурировать с гну греп? Вы серьёзно? Посмотрите на цифры ещё раз: менее 3х минут и более 60...
Ни разу не удавалось подобного результата добиваться, у меня всегда rg работал лучше. Что ж, значит ripgrep еще не так хорош и ему есть над чем работать, все же GNU grep куда более зрелая тула. Попробую воспроизвести что-то подобное у себя. Пока не очень получилось.
Честно говоря, не представляю, как вы такого добились и уже подумываю забрать свои слова назад. Скорее всего проблема в количестве файлов - на огромном числе файлов я еще не проверял.Я зарекался чиселки кидать, но ладно. Нашел рандомные логи http://www.almhuette-raith.at/apache-log/access.log (906M)
> time rg '(\[.*?\]+)' access.log | wc -l
4595960
real 0m1.306s
user 0m1.206s
sys 0m0.577s> time grep -P '(\[.*?\]+)' access.log | wc -l
4595960
real 0m2.329s
user 0m2.101s
sys 0m0.949sБольше всего отличился ag:
> time ag '(\[.*?\]+)' access.log | wc -l
4595960
real 0m22.608s
user 0m22.472s
sys 0m0.986sПосле я рандомным образом изменил паттерн.
> time rg '(\[.*?\]+).*test' test.log | wc -l
6302
real 0m0.266s
user 0m0.203s
sys 0m0.072sНи для grep, ни для ag я результата дождаться не смог. Не знаю, с чем это связано (скорее всего с этим: https://mariusschulz.com/blog/why-using-the-greedy-in-regula... - потому вдвойне забавно, что rg это спокойно прожевал), но сейчас нет возможности доводить эксперимент до конца.
Может хватит обзывать "школьными хипстерскими поделками" все, что вам лично не нравится по идеологическим причинам? Потому что лично вы себя ведете как самый обыкновенный школьник-задира.
> Я зарекался чиселки кидать, но ладно. Нашел рандомные логи http://www.almhuette-raith.at/apache-log/access.log
> (906M)(В)брошу свои чиселки:
>> time rg '(\[.*?\]+)' access.log | wc -l
> 4595960
> real 0m1.306s
> user 0m1.206s
> sys 0m0.577s
>> time grep -P '(\[.*?\]+)' access.log | wc -l
> 4595960
> real 0m2.329s
> user 0m2.101s
> sys 0m0.949sс tmpfs, лучший результат 4 запусков
% time rg -c '(\[.*?\]+)' access.log
4596036
rg -c '(\[.*?\]+)' access.log 1,46s user 0,17s system 99% cpu 1,632 tota% time rg -c -j1 '(\[.*?\]+)' access.log
4596036
rg -c -j1 '(\[.*?\]+)' access.log 1,46s user 0,15s system 99% cpu 1,607 total
time /usr/local/bin/grep -cP '(\[.*?\]+)' access.log
4596036/usr/local/bin/grep -cP '(\[.*?\]+)' access.log 3,53s user 0,28s system 99% cpu 3,813 total
> Ни для grep, ни для ag я результата дождаться не смог. Не
> знаю, с чем это связано (скорее всего с этим: https://mariusschulz.com/blog/why-using-the-greedy-in-regula...
> - потому вдвойне забавно, что rg это спокойно прожевал), но сейчас
> нет возможности доводить эксперимент до конца.Тут уже находили анти-паттерн для rg:
seq 100000000 > fstfiletime rg -ic 1 fstfile
47400465
rg -ic 1 fstfile 5,10s user 0,13s system 99% cpu 5,237 totaltime /usr/local/bin/grep -ic 1 fstfile
47400465
/usr/local/bin/grep -ic 1 fstfile 4,28s user 0,35s system 99% cpu 4,640 total
time /usr/local/bin/grep -ic "^1" fstfile
11111113
/usr/local/bin/grep -ic "^1" fstfile 3,02s user 0,33s system 99% cpu 3,351 totaltime rg -ic "^1" fstfile
11111113
rg -ic "^1" fstfile 7,77s user 0,24s system 99% cpu 8,019 total
Но это уж совсем синтетика - стоит добавить пару знаков и разница уходит:
time rg -ic "^12" fstfile
11111
rg -ic "^12" fstfile 1,83s user 0,19s system 99% cpu 2,020 total
time /usr/local/bin/grep -ic "^12" fstfile
11111
/usr/local/bin/grep -ic "^12" fstfile 2,69s user 0,32s system 99% cpu 3,017 total
Удивительно правда, что у здешнего анонима _все_ оказалось антипаттерном, да еще и c разницей на порядки.
> Удивительно правда, что у здешнего анонима _все_ оказалось антипаттерном, да еще и c разницей на порядки.Вот потому я и не хотел играть в эти идиотские чиселки. Всегда можно подобрать удобное окружение и подходящие данные, для которых чиселки какие надо получатся. Для такого инструмента как grep, в конечном счете все определяет только личная статистика использования на повседневных задачах. Моя такова, что на моих задачах и на моих машинах rg выигрывает.
Но раз уж я влез в эту глупость, все-таки проверил grep и ag:
> time grep -P '(\[.*?\]+).*test' test.log | wc -l
6302
real 9m2.752s
user 9m2.289s
sys 0m0.080s> time ag '(\[.*?\]+).*test' test.log | wc -l
6302
real 8m34.161s
user 8m33.436s
sys 0m0.100s
1 файл это не спортивно. Лично мне нравится руст, но не нравится результат где примитивная утилита сливает в 20 раз на типичном юзкейсе.
> Хорошо, реальный юзкейс. Грепнул 1.1гб текста/1100000 файлов (сущий пустяк, в принципе,
> во всяком случае для меня и моих данных) и чёт совсем
> грустно стало. В общем, прекращайте фейкомётить.Ну вот вам:
find /usr/src -type f |wc -l
83928
du -sh /usr/src
2,5G /usr/src
результат третьего запуска греп (чтоб точно искать с кэша):
grep --version
grep (GNU grep) 3.3
Copyright (C) 2018 Free Software Foundation, Inc.time /usr/local/bin/grep -RPo '(\[.*?\]+)' /usr/src |wc -l
1093008
/usr/local/bin/grep -RPo '(\[.*?\]+)' /usr/src 8,14s user 1,85s system 99% cpu 9,995 total
wc -l 0,12s user 0,00s system 1% cpu 9,994 totaltime rg -uuuo '(\[.*?\]+)' /usr/src |wc -l
1093006
rg -uuuo '(\[.*?\]+)' /usr/src 3,22s user 3,22s system 354% cpu 1,818 total
wc -l 0,10s user 0,22s system 17% cpu 1,815 total
в один тред
% time rg -uuuo -j1 '(\[.*?\]+)' /usr/src |wc -l
1093006
rg -uuuo -j1 '(\[.*?\]+)' /usr/src 2,02s user 1,70s system 99% cpu 3,728 total
wc -l 0,09s user 0,02s system 2% cpu 3,726 total
Потребление памяти: 18МБ RES.Похоже кто-то, не будем указывать пальцем на анонима, собрал дебаг-билд и бодро с ним сравнил релиз билд grep. Ну или точные опции запуска - в студию!
В догонку:rg --version
ripgrep 11.0.2
ok, grep ядра (без кэшей), 0.5 мб памяти в пике, 2.5 shared
2863real 0m17.642s
user 0m4.675s
sys 0m1.727s
rg (без кэшей, упал?), 1мб памяти в пике плюс 5.5 shared
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:378:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
2862real 0m18.099s
user 0m0.976s
sys 0m1.803s
в 4 потока rg
2862real 0m5.618s
user 0m0.784s
sys 0m1.573sСправедливости ради повторный запуск grep
real 0m5.130s
user 0m4.546s
sys 0m0.539sповторный запуск rg
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:378:21
stack backtrace:
0: <unknown>
1: <unknown>
2: <unknown>
3: <unknown>
4: <unknown>
5: <unknown>
6: <unknown>
7: <unknown>
8: <unknown>
9: <unknown>
10: <unknown>
11: <unknown>
12: <unknown>
13: <unknown>
14: <unknown>
15: <unknown>
16: <unknown>
17: __libc_start_main
18: <unknown>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
2862real 0m1.035s
user 0m0.540s
sys 0m0.459s
rg в 4 потока
2862real 0m0.721s
user 0m0.559s
sys 0m0.518sпо-моему всё это множится на 0 фактом того, что данных мало и они синтетические в рамках данного "теста".
Вон я же дал датасет приближенный к реальным данным, почему не используете его? http://ftp.freedb.org/pub/freedb/freedb-complete-20191203.ta...
Ну и стоит всё же использовать hdd, на ssd вы много данных не разместите.
>дебаг-билд
нет
> rg (без кэшей, упал?), 1мб памяти в пике плюс 5.5 sharedЧего-чего, но падений я еще не видел.
> Вон я же дал датасет приближенный к реальным данным, почему не используете
> его? http://ftp.freedb.org/pub/freedb/freedb-complete-20191203.ta...Наверное, потому что не влезет в tmpfs, да и качаться будет минут 10?
> Ну и стоит всё же использовать hdd, на ssd вы много данных не разместите.
Это мне в ящике стола ковыряться, хард искать, подключать … да и какой смысл измерять скорость чтения с диска, в который все и упрется (если оно не поместится в кэше).
>>дебаг-билд
> нетНо билд, судя по паникам - кривоват.
Мне Раст интересен. Но растаманы оталкивают тем что серят в адрес Юникса, ГНУ и Си.
В семье не без... разнообразия. Не знаю, кто занимается такими глупостями, но не обращайте внимания. Изучайте себе язык в удовольствие и не слушайте поехавших - их везде хватает.Если бы не C, Rust никогда бы не появился. Rust имеет много корней, в том числе сугубо функциональных, но достоинства и недостатки C в значительной степени повлияли на дизайн Rust. Глупо высмеивать C просто потому, что он не в состоянии дать те же возможности и гарантии, что и Rust, в силу необходимости поддерживать обратную совместимоть. То же с GNU и UNIX - все новое строится на их достижениях и ошибках. Как тут можно что-то высмеивать.
> Или это и была цель?Что за глупый вопрос? Смысл родительского коммента сводится к "не нужно", какая ещё цель кроме провокации cpaча могла за этим стоять?
> В новой версии добавлена опция "--no-ignore-case", отключающая действие настроек отмены учёта регистра символов (-i, --ignore-case).Теперь осталось добавить опцию --cancel-no-ignore-case[=false]
--switch-off-disable-cancel-no-ignore-case[=false[=true]]
остаётся только значение по умолчанию сделать рандомным
А может кто-то поделиться с домохозяйкой http://www.gnu.org/software/grep/manual/grep.html только на русском?
гулугулу какие-то куски даёт?
> А может кто-то поделиться с домохозяйкой http://www.gnu.org/software/grep/manual/grep.html
> только на русском?
> гулугулу какие-то куски даёт?оно?
https://www.opennet.me/man.shtml?topic=grep&russian=0&catego...
https://www.google.com/search?q=grep+%D0%B4%D...
не знаю как "гулугулу", а тындекс выдал по запросу "man grep" в первую очередь на русском и первая ссылка на самом опеннете: https://www.opennet.me/man.shtml?topic=grep&category=1
не знаю, что за тындэкс, но гугл первой ссылкой выдаёт на русском. а ещё знаю, где запятые ставить
хотелось бы исключения файлов по маскам или по крайней мере упрощение
> хотелось бы исключения файлов по маскамПочитай про гну-тулбокс, и не проси глупостей. Чтобы выбирать файлы или исключать файлы есть find.
Делай так: find <find-options> -exec grep -H <grep-options> {} \;
> упрощение
Упрощение чего?
мне в git grep нужно
> мне в git grep нужноgit-grep(1) до pathspec дочитайте :-)
Заметил, что режим угадываний малоэффективен. Разумеется в курсе, что git grep 123 -- *.cМне надо, чтобы набор масок читался откуда-то из пременных окружений, это раньше работало и вопросов не было.
> Заметил, что режим угадываний малоэффективен. Разумеется в курсе, что git grep 123
> -- *.c
> Мне надо, чтобы набор масок читался откуда-то из пременных окружений, это раньше
> работало и вопросов не было.cat >>~/.bashrc
function git-grep() {
git grep $* -- $SOURCE_FILES_PATTERNS
}
^D
exec bash -l
Благодарю,мне представляется это неплохим решением,
но не очень понятно как это адаптировать для применения в https://github.com/yasuyk/helm-git-grep
> Благодарю,
> мне представляется это неплохим решением,
> но не очень понятно как это адаптировать для применения в https://github.com/yasuyk/helm-git-grepЕсли я правильно понимаю, то как-то так:
cat >>~/.emacs
(setq helm-git-grep-pathspecs (getenv "SOURCE_FILES_PATTERNS"))
^DМожет не совсем так, может придётся распарсить $SOURCE_FILES_PATTERNS на отдельные слова, и засунуть в helm-git-grep-pathspecs список слов. Может быть я неправильно понимаю назначение helm-git-grep-pathspecs, и тогда надо будет найти подходящую переменную, или даже создать эту переменную и кинуть в тот github-реп пулл-реквест. Это уже детали, с которыми ты сам можешь разобраться.
не, не делай ТАК.
Прочитай, все же, пока не запретили как неполиткорректную писанину, книжку Кернигана, про юникс, а не про какой-то там gnushitbox. Этим "новым стандартам" вряд ли суждено прожить тридцать лет, как тем.Скорее всего, отправятся на помойку, как немодные, еще лет через пяток.
Заодно - сам, без дополнительных пояснений, сообразишь, после прочтения и, разумеется, понимания, почему это никуда не годная привычка (а владеющему немодным слепым набором - еще и неудобнее набирать, чем правильный вариант)
> Прочитай, все же, пока не запретили как неполиткорректную писанинуХозяйке на заметку: этот же организм в соседней теме про CCC бредил полониевым новичком -- похоже, избирательно доверчив, аки дитя малое... ну а здесь find(1) записал в отходы. Возможно, всё-таки "просто" с бодуна такое полезло.
Другое дело, что предусмотрительному человеку бывает полезно ещё и о пробелах подумать хотя бы -- см. самое начало http://altlinux.org/spp
PS: хотя K&P про универсальную среду программирования -- хороший совет, ага.
> Заодно - сам, без дополнительных пояснений, сообразишь, после прочтения и, разумеется, пониманияНе, я не буду читать Кернигана, только для того, чтобы выяснить что-нибудь в стиле "правильный вариант передавать список файлов из find в grep -- пайп, а всё остальное -- неправославно". Мне не интересно это. Ну реально, догмы мне надоели. Я переключился на борьбу с догмами, но и это мне надоело последнее время. Поэтому оставь этот сборник догм за авторством Кернигана себе. Просто перечитай его сам, отдохни душой, просветлись умом. Но не надо мне его подсовывать.
> владеющему немодным слепым набором - еще и неудобнее набирать, чем правильный вариант
Слепой набор, наоборот очень моден, тут ты что-то путаешь. Сколько раз твердили админам и кодерам, что он им бесполезен, что если они заняты делом а не туфтой, то 300 зн/мин они не смогут набирать ни при каких условиях, что для того, чтобы набрать пару тысяч строк кода за рабочий день* им и 60 зн/мин хватит за глаза и за уши, а они всё равно дpoчат на слепой набор.
*) Это кстати кто-то из тех самых патриархов юникс заялял -- Керниган, Ритчи или Томпсон, -- что в самые продуктивные свои дни, ему удавалось набрать пару тысяч строк кода.
И я не вижу никаких проблем набрать приведённое выше слепым набором. Даже более того, отсутствие пайпа избавляет от необходимости тянуться мизинцем левой руки куда-то далеко. Меня в find вечно напрягает то, что стартовый путь для поиска надо ставить до шаблона имени искомых файлов -- это понятно логически, но моя голова уже лет двадцать не может привыкнуть, потому что она думает мысль в обратном порядке: сначала "что" ищем, и только затем "где" ищем. Но это ведь будет раздражать вне зависимости от зрячести набора, так?
> Я переключился на борьбу с догмами, но и это мне надоело последнее время.Луговский похожую дорожку проходил несколько раньше -- возможно, Вам бы оказалось интересно его найти да потолковать. В его случае критически важным оказалось то, что он по-научному честен, насколько могу судить.
Что есть ГНУ? Хорошую вещь ГНУ не назовут.