Есть кто-то шарящий в fzf и grep?

fzf --tiebreak=index и/или --scheme=history?

Честно говоря, это же классически идеальный вопрос для GPT:

Проблема, с которой вы столкнулись, заключается в том, что когда вы начинаете вводить что-то для поиска в fzf, он начинает сортировать результаты исходя из того, как хорошо они соответствуют вашему запросу поиска, а не основываясь на исходной сортировке (которая у вас по датам в именах файлов).

Чтобы сохранить исходный порядок файлов вне зависимости от поискового запроса в fzf, вы можете использовать параметр --no-sort для fzf:

grep -r "" * | fzf --exact --no-sort

Эта опция заставит fzf выводить результаты в том порядке, в котором они поступают на его вход, что, в вашем случае, соответствует сортировке по датам в именах файлов логов.

Однако, учтите, что если grep будет выдавать результаты в неотсортированном порядке (к примеру, если файлы будут обработаны не по порядку), то --no-sort не решит проблему сортировки как таковую. В таком случае, может понадобиться явно отсортировать вывод grep перед передачей его в fzf. Если порядок файлов важен и grep может в некоторых обстоятельствах выводить их не в нужной последовательности, вы можете использовать sort:

grep -r "" * | sort | fzf --exact --no-sort

Тут sort сортирует весь вывод grep по алфавиту (который, благодаря формату ваших имен файлов, совпадает с календарным порядком), а fzf затем показывает результаты в этом порядке, не меняя его при поиске.

Это должно помочь сохранить результаты в нужном порядке независимо от того, что ищется в fzf.

Тут sort сортирует весь вывод grep по алфавиту (который, благодаря формату ваших имен файлов, совпадает с календарным порядком)

02012023 > 01022023, ага.

Советую попробовать ugrep: $ ugrep -Q -Z --sort=best -%.

Все перепробовал… Либо не сортирует, либо сортирует, но почему-то по первым двум цифрам:

01042023.log
02012023.log
03022023.log
04012023.log

Главное ж, как только запускаешь команду, все отсортировано как надо. Не могу понять, что ему не так :(

Попробовал, забавная штука, но сортирует тоже по первым двум цифрам. И еще: как заставить его искать строгую последовательность символов, а не все, что имеются в файлах?

Все перепробовал… Либо не сортирует, либо сортирует, но почему-то по первым двум цифрам:

Стоп, ну естественно, я видимо совсем уже не соображал вечером. У тебя порядок алфавитной сортировки не совпадает с хронологическим.

А в самом начале всё отсортировано как надо потому что файлы в каталоге, скорее всего, создавались в хронологическом порядке, и readdir их возвращает в порядке линейного прохода по таблице каталога (у тебя ведь какая-нибудь ext3/4?).

fzf --scheme=history --tiebreak=index --no-sort

как заставить его искать строгую последовательность символов

-F -e <строка>

файлы в каталоге, скорее всего, создавались в хронологическом порядке, и readdir их возвращает в порядке линейного прохода по таблице каталога

Что абсолютно ничего общего с хронологией не имеет (а ловко вы отредактировали).

(у тебя ведь какая-нибудь ext3/4?).

Началось. Можно подумать ваша глубоко любимая btrfs чем то отличается. Я уверен - её развалить мне усилий займёт меньше.

То же самое. Да, файлы создавались +/- хронологически, но в конце каждого лога есть пару записей уже следующего дня. Соответственно, дата создания лога > даты в имени файла на единицу. Но я не думаю, что это должно влиять, ведь при запуске команды все правильно отсортировано по имени файлов в формате даты.

А потом сортировка ломается и работает только с первыми двумя цифрами.

Это от того, что fzf наиболее релевантные варианты представляет снизу вверх:

seq 0 19 | fzf

У него нет «наиболее релевантных» (или «наименее релевантных»). Это просто поиск. Развернуть его можно опцией –reverse, но мне не это вовсе нужно.

Можно у файлов предварительно поменять дату создания на что-то одно. Не вопрос. Лишь бы работала сортировка.

Это просто поиск

Вот он и сортирует в порядке лексических соответствий тому, что вы ввели, а не строки в целом.

А теперь перечитай то, что я написал. Если пытаться отсортировать твои строки в алфавитном порядке, как раз и получится «сортировка по первым двум цифрам», которая не совпадает с правильной сортировкой по датам.

А «правильная сортировка по датам» — это просто перечисление файлов в порядке их появления в командной строке grep (после раскрытия *), то есть банально в порядке readdir. Который, скорее всего, и совпадает с хронологическим, потому что твои файлы создавались именно так.

Я только что потестировал на синтетических данных твоего формата. fzf --no-sort работает как ты хочешь. Можешь ещё попробовать fzf --no-sort --reverse, чтобы было заметнее.

ведь при запуске команды все правильно отсортировано по имени файлов в формате даты.

Сортирует сама ls.

А потом сортировка ломается

Если кто-то активно создаёт файлы, пусть даже хронологически, пусть даже с именами заранее определённого (лексиграфически-хронологически-naturally отсортированного) формата - правильно (atomically, без пропусков) это вычитать занимает определённых усилий. readdir не хватает.

Тебе не нужно менять дату создания файлов, она ни при чём.

Есть подозрение, что тебя вопрос btrfs почему-то волнует гораздо сильнее, чем меня. Интересно, с чего бы это.

Что абсолютно ничего общего с хронологией не имеет

Естественно, имеет. Если мы имеем дело с классической ФС, которая хранит directory entries в линейном массиве или эквивалентной структуре, то порядок их перечисления с помощью readdir будет, внезапно, совпадать с порядком их создания (фактического).

Началось. Можно подумать ваша глубоко любимая btrfs чем то отличается

Интересно. Фанатиком ты называешь меня, а помешательство у тебя. При чём тут вообще btrfs? И при чём тут «разваливаемость»?

Но если мы уж заговорили, то да, отличается — банально потому что она всегда хранит directory entries в B-дереве, где ключи этого дерева всегда представляют собой хэши от имён файлов. Поэтому в btrfs порядок перечисления файлов непредсказуем, т. к. readdir тупо идёт по дереву слева направо от lower bound ключей данного каталога до upper bound этого же каталога. А в ext3/4, пока размер каталога не превысит один блок, это не так, и directory entries хранятся линейно в порядке создания. Вот и всё.

Сортирует сама ls

А теперь покажи в треде хотя бы один вызов ls, умник.

то порядок их перечисления с помощью readdir будет, внезапно, совпадать с порядком их создания (фактического).

Да что вы говорите. Реально?? Вас много ждёт «открытий чудных».

Блин! Это почти то, что мне надо! Но… не могу заставить выборку делать строгую. И да, мне нужна не команда с запросом (как ты предлагаешь), а на лету писать туда запрос. Не могу чет разобраться в его опциях… Вроде -w должна указывать на поиск «только полного слова», но все равно при вводе a34 выбирает a034, а394, а324 и т.д. Ну ты понял.

Ясно, спасибо большое за уделенное время. Буду разбираться. Тут еще ugrep посоветовали, он мне кажется удобнее, только разберусь со строгим поиском в нем. Вообще ништяк. Благодарю еще раз.

Вроде -w должна указывать на поиск «только полного слова»

Тогда нужно убрать -Z: ugrep -Q -w -F -e <строка>

а на лету писать туда запрос

А подробнее?

А подробнее?

Ну он же интерактивный. Я просто запускаю из директории ugrep -Q -Z --sort=best -% и вперед, печатаешь в строке поиска что надо. Но не могу в интерактивном режиме заставить искать строгую последовательность символов, например, ab3.

Разве $ ugrep -Q -w -F --sort=best -% не то?

Пишет [no matches found], хотя оно там все есть. Хз, почему так. Спрошу еще помощи у чавака на гитхабе.

Да, похоже на баг. Я проверял на версии 5.0.

Если это логи, то именовать их надо в соответствии с RFC-3339/ISO-8601, тогда проблем с сортировкой не будет в принципе. Формат DMY (в любых его проявлениях; да-да, maxcom, почему это моё сообщение датировано 24 февраля 2020 года?) — самая дебильная практика, которую только можно было избрать. Сами себе палок в колёса навставляют, и потом героически с этим борятся…

Если нет возможности изменить именование (на этапе генерации, разумеется) файлов, то стоит сортировать по ctime:

ls -U1 . | xargs -n1 cat | ...

Я чуток нуб. Вот так?

ls -U1 . | xargs -n1 cat | grep -r "" * | fzf

Я идиод, убейте меня (с)

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

Мне просто вдруг захотелось невозможного, чтобы сортировало «правильно» по датам, вот так:

01012023.log:01.01.2023 (time) (login) (etc) IP address (CONNECT)
01022023.log:01.02.2023 (time) (login) (etc) IP address (CONNECT)
01032023.log:01.03.2023 (time) (login) (etc) IP address (CONNECT)
01042023.log:01.04.2023 (time) (login) (etc) IP address (CONNECT)

Такое вообще возможно как-то насобачить в баше или прочими grep/awk тулзами или товарищ выше таки прав, что такой формат даты - зло и ССЗБ ?

Такое вообще возможно как-то насобачить в баше или прочими grep/awk

Как вариант натравить на awk поменяв поля местами.

Добавлю, что в пятую версию добавили ключ --index для поддержки индексов утилиты https://github.com/Genivia/ugrep-indexer, которая рекурсивно создаёт индексы в каждой директории.
Проверил – поиск существенно ускорился.

ugrep мне нравится даже больше, он нагляднее что ли. Осталось только решить проблему строгого поиска (конкретно заданной последовательности) символов.

В общем, поборол. :)
Если скомпилировать с поддержкой pcre2, то ugrep -Q -P -F --sort=best -% работает.

В Арче оно вроде и так включено. По крайней мере в PKGBUILD такое:

depends=(bzip2
         lz4
         pcre2
         xz
         zlib
         zstd)

А там какая версия, пятая?

$ ugrep --version
ugrep 5.0.0 x86_64-pc-linux-gnu +avx2; -P:pcre2jit; -z:zlib,bzip2,lzma,lz4,zstd
License: BSD-3-Clause; ugrep user manual: <https://ugrep.com>
Written by Robert van Engelen and others: <https://github.com/Genivia/ugrep>
Ugrep utilizes the RE/flex regex library: <https://github.com/Genivia/RE-flex>

Да, пятая. Не, все нормально! Опция работает и так. Спасибо тебе огромное за подсказки и потраченное на меня время! :)

Зачем тебе тут grep? Оно же тупо выплюнет всё как есть, что уже делает cat. В твоём случае достаточно так:

ls -U1 . | xargs -n1 cat | fzf

Даже в изначальном варианте достаточно было сделать просто cat *, ибо grep -r "" * это рекурсивно вывести содержимое файлов (рекурсивно, любой вложенности, но у тебя же плоский список без вложенных директорий?) по пустому паттерну (то есть любое вхождение). Если же у тебя там имеются директории, в которых тоже нужно искать, то тут придётся действовать чуть сложнее, и надёжнее будет использовать find+stat (но это долго/дорого).

Можно написать скрипт, который парсит твои логи и формат в них, но конвертировать из non-RFC3339 больно (на самом деле не очень, но всё равно), потому это останется на тебе. (=

Просто кое-кому надо иногда читать мануалы… :(

таки прав, что такой формат даты - зло и ССЗБ ?

Не очень подходящая аналогия: Найди нужный номер дома, затем найди нужную улицу, затем нужный город. Так и с датами: ты вначале сортируешь по числу (неизвестного месяца), затем по месяцу (неизвестного года), и только затем по году. Каждый следующий шаг ломает предыдущий.

ugrep -Q -P -F --sort=created -%

Вообще песня! Я добился того, чего хотел. Респект и спасибо.

Блин, туплю. Вот так, конечно же:

01012023.log:01.01.2023 (time) (login) (etc) IP address (CONNECT)
02012023.log:01.02.2023 (time) (login) (etc) IP address (CONNECT)
03012023.log:01.03.2023 (time) (login) (etc) IP address (CONNECT)
04012023.log:01.04.2023 (time) (login) (etc) IP address (CONNECT)

Сначала дни, потом месяцы.

Это опция грепа? Как сделать, чтобы сначала сортировалось по дням, потом по месяцам? (я тебя, наверное, задолбал уже сегодня, прости)

то порядок их перечисления с помощью readdir будет, внезапно, совпадать с порядком их создания (фактического).

Да что вы говорите. Реально?? Вас много ждёт «открытий чудных».

Поправлюсь - то что вы сказали возможно будет справедливо только если из директории ничего не удаляли, никогда. Гораздо более интересная (и жизненная) ситуация возникает если у вас имеется producer + consumer, и число актуальных файлов остаётся более-менее константой.