Проект GNU опубликовал выпуск пакета findutils 4.10.0,  включающего реализации утилит для организации поиска файлов в системе, таких как find, updatedb и locate, updatedb. В составе findutils также развивается утилита xargs, предназначенная для построения команд, выполняемых с данными из стандартного ввода, обычно формируемых при помощи утилиты find...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61479

• Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,Аноним, 11:53 , 03-Июл-24
  • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,Аноним, 11:57 , 03-Июл-24
    • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,Аноним, 22:20 , 03-Июл-24
  • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,Аноним, 12:52 , 03-Июл-24
    • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,Аноним, 13:25 , 03-Июл-24
      • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,Ананимус, 19:08 , 03-Июл-24
    • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,Аноним, 13:31 , 03-Июл-24
      • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,Аноним, 13:52 , 03-Июл-24
        • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,Аноним, 13:54 , 03-Июл-24
          • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,Аноним, 14:31 , 03-Июл-24
        • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,noc101, 16:52 , 03-Июл-24
      • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,YetAnotherOnanym, 20:35 , 03-Июл-24
        • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,Аноним, 06:55 , 04-Июл-24
          • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,1, 09:32 , 04-Июл-24
          • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,YetAnotherOnanym, 22:33 , 04-Июл-24
        • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,Аноним, 18:02 , 08-Июл-24
          • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,YetAnotherOnanym, 15:41 , 10-Июл-24
• Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,wd, 12:25 , 03-Июл-24
  • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,Аноним, 04:28 , 04-Июл-24
• Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,Соль земли, 12:36 , 03-Июл-24
  • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,Аноним, 14:51 , 03-Июл-24
  • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,Аноним, 04:28 , 04-Июл-24
    • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,Аноним, 15:52 , 04-Июл-24
    • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,Ахз, 16:37 , 05-Июл-24
      • Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,Аноним, 18:05 , 08-Июл-24
• Выпуск набора утилит GNU findutils 4.10.0 с возобновлением п...,Аноним, 02:32 , 04-Июл-24

В таких утилитах раст неуместен.

Конечно, товарищъ майор!
Так же вам будет сложнее внедрять уязвимости вида "опять вышли за пределы буфера" ну с кем не бывает.
Это ведь нормально для дыряшки и ее любителей!

Вспомните, где появился С/С++.

Так что не "товарищь майор", а "мистьер дьемократьичьеский капрал (не негр)".

Что реально досадно, они эти утилиты реализовали дидовским методом. Не в виде набора библиотек, к которому утилиты командной строки играют лишь роль транслятора командной строки в вызовы методов. Башпортянки заменять программами на расте всё ещё боль.

Кстати а чего не сделал форк которые сделает библиотеку из программы? Может потому что никому не надо?

Так есть, fd. И он работает ГОРАЗДО быстрее:

$ time fd src >/dev/null
fd src > /dev/null  1.07s user 0.70s system 2078% cpu 0.085 total
$ time find src >/dev/null  
find src > /dev/null  0.14s user 0.56s system 38% cpu 1.831 total

Как бы параллельность рулит и педалит .

не задумывались о том что если так не сделали до сих пор то это никому не нужно

Задумывался, и поэтому я рылся в issues uutils, и нарыл там обсуждение этой идеи. Это было давно, лет пять(?) наверное назад, и разработчики такие "о, да хорошая идея, но... это ж сколько переписывать надо... жаль что нам не пришло это в голову раньше".

> Задумывался, и поэтому я рылся в issues uutils, и нарыл там обсуждение этой идеи. Это было давно, лет пять(?) наверное назад, и разработчики такие "о, да хорошая идея, но... это ж сколько переписывать надо... жаль что нам не пришло это в голову раньше".

Странно. У них первый релиз был в 2020м.
По идее это относительное начало проекта.
Может они хотели поддерживать легаси?

Все проще они не умеют программировать.

ну то есть это никому не нужно!)
Было бы нужно, что то сделали. А так покивали, покивали и дальше пошли.

Вообще-то - нужно. Критически нужно. Архинужно. Только проблема в том, что скриптом@к@ки не осознают, насколько это нужно.
Выделение отдельно оформленной либы, в которой реализована вся "полезная нагрузка", позволило бы использовать её функциональность в скриптах (на языках, допускающих подключение сторонних .so) без вызова утилиты в дочернем шелле, а это исключило бы целый класс уязвимостей.

>Выделение отдельно оформленной либы, в которой реализована вся "полезная нагрузка", позволило бы использовать её функциональность в скриптах (на языках, допускающих подключение сторонних .so) без вызова утилиты в дочернем шелле, а это исключило бы целый класс уязвимостей.

Экосистема GNU/Linux всегда так работает. С разморозкой тебя.

Он про винду ... dll ему не хватат

> В зкосистеме GNU/Linux я всегда только так умел работать

Пофиксил

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

писать универсальную либу - это колхозить какой-то аналог sql или nosql и конечно же find без grep это полумера, в результате получится комбайн для которого надо будет писать огромный туториал, и чего ради?

В абсолютном большенстве кейсов рекурсивный обход не нужен, а даже если нужен, надо четко понимать что и как обрабатывать, обычно это просто отдельная задача - убрать дубликаты, битые файлы, и прочий мусор, а вот уже потом делать чтото

> и чего ради?

Ради избавления от некоторого типа уязвимостей.

поиск по xattr бы...
а если бы еще и индексы по ним...

О, я давно хочу пропатчить slocate на индексирование xattr. Сколько вы готовы заплатить, чтобы я наконец этим занялся?

Казалось бы, какое отношение суперполезный xargs имеет к поиску чего-либо? Впрочем find и xargs очень хорошо объединяются, позволяя выполнить команду один раз сразу ко всем найденным файлам.

может по одному разу к каждому из найденых?

find . -exec лучше любого xargs

Только xargs скорее про параллельное исполнение команд для наборов данных, например, find поставляет список интересующих путей/файлов и xargs их одновременно обрабатывает запуская команды с требуемыми условиями и ограничениями (и findutils такой функциональности не предосталяют, насколько мне известно).

Ага, сразу видно кексперта.
Как у тебя выстраивается команда в своей конструкции знаешь ?
Сначала отработает весь поиск а потом результат пойдет выполнение командой в виде позиционных переменных. И весело получишь too many arguments. Поэтоум единственный правильный вариант вот такой

-print0 | xargs -0 команда

Наберут, блин, по объявлению...
Не, хотя если работать в /home/student_02/, то никогда не столкнешься с подобной проблемой :D

И вопрос со звездочкой, на 5-ку - угадай почему print0, а не просто print ? :D

>  Ага, сразу видно кексперта.

find -exec - мне на прошлой недели 6 миллионов файлов обработал из примерно 30, давай расскажи ага

Поддержка musl это хорошо!

> GNU Test Suite
> BFS Test Suite

Сегодня что-то новое узнал.