LINUX.ORG.RU

ugrep 7.1 и 7.1.1

 , , , ,

ugrep 7.1 и 7.1.1

1

4

22 и 30 ноября состоялись выпуски 7.1 и 7.1.1 быстрой кроссплатформенной консольной утилиты поиска текста ugrep, написанной на языке C++ и распространяемой по лицензии BSD-3.

Для более эффективного поиска в больших файловых системах на медленных носителях, или при поиске во многих архивах (zip, tar и др.), можно предварительно выполнить индексирование утилитой ugrep-indexer (входит в поставку ugrep, начиная с версии 6.0).

Список изменений:

  • добавление подсветки синтаксиса шаблонов поиска и другие улучшения TUI;
  • добавлена поддержка опции --filter (Windows);
  • обеспечена работа дополнительных скриптов ug+ и ugrep+ при недоступности вспомогательных конвертеров файлов (pdftotext, Poppler, antiword, pandoc или exiftool);
  • исправлено инвертирование классов символов при использовании опции -i (или --ignore-case) для соответствия с поведением GNU grep при использовании опций -i и -P;
  • устранены некоторые предупреждения -Woverload-virtual и -Wshadow при сборке библиотеки RE/flex, TUI и индексатора ugrep-indexer.

>>> Подробности

★★★★★

Проверено: CrX ()
Последнее исправление: CrX (всего исправлений: 2)

Для более эффективного поиска в больших файловых системах на медленных носителях,

больших файловых системах

Честно говоря, не особо понимаю, как размер ФС на это вообще влияет, да и в оригинале этого не вижу.

Сам не тестил случаем, как оно?

CrX ★★★★★
()
Ответ на: комментарий от CrX

да и в оригинале этого не вижу.

Please note that indexing is effective for large file systems on slower storage media or when searching many zip and tarball archives. Indexing won’t speed up regular file searching on fast nVME SSDs, for example.


Сам не тестил случаем, как оно?

Тестировал на HDD/Btrfs+zstd, хорошо. :)

dataman ★★★★★
() автор топика
Последнее исправление: dataman (всего исправлений: 1)
Ответ на: комментарий от CrX

как размер ФС на это вообще влияет

Фраза «большой размер ФС» как-бы подразумевает «100ТБ старый и поганый составной массив на убогих дисках, полностью засраный невменяемым количеством мелких файлов». Без индекса тут вообще никак.

Интересно, сколько бы собирался индекс на таком диске: гогол лет, или гоголплекс, хммм?)

somemong
()

Хорошая тулзень, когда нужно быстренько что-то глянуть в логе, который на пару десятков гигов. Под Фряшкой можно его сбилдить с портов добавив поддержку AVX и SSE2.

iron ★★★★★
()
Ответ на: комментарий от dataman

Уже понял. Просто выпустили новее версию с фиксами. Почему-то подумал сначала, что это две ветки. Ты так не делай больше, в чем смысл? :)

Gonzo ★★★★★
()
Ответ на: комментарий от Gonzo

в чем смысл?

Список солидней. :)

dataman ★★★★★
() автор топика
Ответ на: комментарий от CrX

Для более эффективного поиска в больших файловых системах на медленных носителях,

больших файловых системах

Честно говоря, не особо понимаю, как размер ФС на это вообще влияет

На HDD, чем ближе данные находятся к концу диска, тем медленнее они пишутся/читаются.

И не надо сейчас про NVMe и прочее. Речь не только о личном ноутбуке.

mord0d ★★★★★
()
Последнее исправление: mord0d (всего исправлений: 1)
Ответ на: комментарий от dataman

Странное, когда из четырёх чисел

Да, не особо понятно:

$ [version]::new('7.5.0.1')

Major  Minor  Build  Revision
-----  -----  -----  --------
7      5      0      1
dmitry237 ★★★★
()
Ответ на: комментарий от mord0d

На HDD, чем ближе данные находятся к концу диска, тем медленнее они пишутся/читаются.

А размер ФС причём? Ближе к концу диска может быть хоть часть данных на большой ФС на весь диск, хоть все файлы на малюсенькой ФС, но расположенной в конце диска.

CrX ★★★★★
()
Ответ на: комментарий от dataman

когда из четырёх чисел

Арч: 0.8.0-2
Дебиан: 6.11.10-1

Почему? Вполне понятно. Как уже написали выше: мажор, минор, билд, ревизия.

Gonzo ★★★★★
()
Последнее исправление: Gonzo (всего исправлений: 1)

Googling files

занятно…

seiken ★★★★★
()
Ответ на: комментарий от dataman

Понятия не имею, у меня нет SSD.

Это такой скуф’ский прикол? Давай я тебе подкину SSD’ху.
Может ты там на CD-ROM’е диски ещё жгёшь…?

Shprot ★★
()

Проверил поиск простой подстроки в проекте. Файлы (~3,500) были подсунуты в аргументы команды. Медленнее всего сработала входящая в состав macOS реализация grep. Затем примерно одинаково сработали GNU grep и p9p grep. Преимущество p9p версии в том, что она не ждёт завершения всего поиска, чтобы вывести результаты, а выводит их постепенно. Ну и ugrep и ripgrep оказались значительно быстрее.

Обидно за p9p: в нём был впервые реализован Thompson NFA. Видимо, ugrep и ripgrep каким-то образом лучше справляются с IO.

kaldeon
()
Последнее исправление: kaldeon (всего исправлений: 1)
Ответ на: комментарий от kaldeon

Видимо, собеседник хочет сказать, что в сабже есть всё, кроме…

hobbit ★★★★★
()
Ответ на: комментарий от CrX

А размер ФС причём?

Черепичная запись, которая применяется на дисках большого объёма.

Невозможно создать файловую систему больше, чем объём диска. Если только это не RAID-0, но там свои нюансы.

mord0d ★★★★★
()
Ответ на: комментарий от kaldeon

При том, что пере-грепалка/недо-фм – это первый шаг к ОС из текстового редактора

buddhist ★★★★★
()
Ответ на: комментарий от CrX

Скорее имелось ввиду - индексирует дерево каталогов для ускорения поиска в медленных файловых системах и файловых системах, которые «холодные», т.е. недавно не кэшировались в памяти.

spawn_sp ★★★★
()
Ответ на: комментарий от spawn_sp

для ускорения поиска в медленных файловых системах и файловых системах, которые «холодные», т.е. недавно не кэшировались в памяти

Да, это я и прочитал на гитхабе. И это вполне логично. А вот откуда именно большие ФС в новости — пытаюсь выяснить.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от Shprot

скуф’ский

Вообще мимо. Советую не использовать слов из новояза, не зная ни их значений, ни «обласканных» ими людей.

Давай я тебе подкину SSD’ху.

В другую страну? Сильно вряд ли.
Но можно деньгами. С нетерпением жду! :-D

dataman ★★★★★
() автор топика
Ответ на: комментарий от dataman

А для чего BuildLabel, для распознавания разлия в сборке одного и того же?

$ [semver]::new(1,2,3,'preview','test-1')           

Major  Minor  Patch  PreReleaseLabel BuildLabel
-----  -----  -----  --------------- ----------
1      2      3      preview         test-1

$ [semver]::new(1,2,3,'preview','test-1').ToString()
1.2.3-preview+test-1

Вообще конструктор в pwsh (.Net) такой:

$ [System.semver]::new                                     

OverloadDefinitions
-------------------
semver new(string version)
semver new(int major, int minor, int patch, string preReleaseLabel, string buildLabel)
semver new(int major, int minor, int patch, string label)
semver new(int major, int minor, int patch)
semver new(int major, int minor)
semver new(int major)
semver new(version version)

dmitry237 ★★★★
()
Ответ на: комментарий от dmitry237

А для чего BuildLabel, для распознавания разлия в сборке одного и того же?

Дата сборки или SHA, например.

  1. Сборочные метаданные МОГУТ быть обозначены добавлением знака плюс и ряда разделённых точкой идентификаторов, следующих сразу за патчем или предрелизной версией. Идентификаторы ДОЛЖНЫ содержать только ASCII буквенно-цифровые символы и дефис [0-9A-Za-z-]. Идентификаторы НЕ ДОЛЖНЫ быть пустыми. Сборочные метаданные СЛЕДУЕТ игнорировать, когда определяется старшинство версий. Поэтому два пакета с одинаковой версией, но разными сборочными метаданными, рассматриваются как одна и та же версия.

Примеры: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.

dataman ★★★★★
() автор топика
Ответ на: комментарий от spawn_sp

Это где такое?

Арч:

https://archlinux.org/packages/extra/x86_64/alsa-plugins/

Объяснение:

https://wiki.archlinux.org/title/PKGBUILD#epoch

Debian:

https://packages.debian.org/bookworm/vim

Объясниение:

https://www.debian.org/doc/debian-policy/ch-controlfields.html#version

Gonzo ★★★★★
()
Последнее исправление: Gonzo (всего исправлений: 1)

The Silver Searcher вызывается сокращением ag, ripgrep — rg. Здесь ug? Было бы в тему.

Upd. Посмотрел мануал — да, ug.

rebforce
()
Последнее исправление: rebforce (всего исправлений: 1)
Ответ на: комментарий от dataman

Если следовать https://semver.org/lang/ru, то ревизия не обязательна.

Это не какая-то абстрактная «ревизия» от разрабов программы. Это патч-номер дистрибутива. То есть версия патча, которую в этом дистрибутиве накладывают на эту версию пакета. Версия 1.2.3-4 означает, что на оригинальный пакет версии "1.2.3" в самом дистрибутиве наложили патч, и версия этого патча - "4".

К примеру:

$ apt show build-essential
Package: build-essential
Version: 12.9
...

Это пакет от самих разрабов дистрибутива, у него патч-номера нет.

$ apt show dmidecode
Package: dmidecode
Version: 3.4-1
Priority: important
...

$ apt show xterm
Package: xterm
Version: 379-1
...

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

$ apt show gcc
Package: gcc
Version: 4:12.2.0-3
...

В этом релизе к gcc уже дважды модифицировали дистрибутивный патч. Кроме того, у gcc - есть номер «эпохи», отличный от нуля - значит схему версионирования пакетов уже меняли четыре раза.

LamerOk ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.