| |
| 2.6, Аноним (-), 11:57, 03/07/2024 [^] [^^] [^^^] [ответить]
| –11 +/– |
Конечно, товарищъ майор!
Так же вам будет сложнее внедрять уязвимости вида "опять вышли за пределы буфера" ну с кем не бывает.
Это ведь нормально для дыряшки и ее любителей!
| | |
| |
| 3.75, Аноним (75), 22:20, 03/07/2024 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Вспомните, где появился С/С++.
Так что не "товарищь майор", а "мистьер дьемократьичьеский капрал (не негр)".
| | |
|
| 2.38, Аноним (-), 12:52, 03/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
Что реально досадно, они эти утилиты реализовали дидовским методом. Не в виде набора библиотек, к которому утилиты командной строки играют лишь роль транслятора командной строки в вызовы методов. Башпортянки заменять программами на расте всё ещё боль.
| | |
| |
| 3.52, Аноним (4), 13:25, 03/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
Кстати а чего не сделал форк которые сделает библиотеку из программы? Может потому что никому не надо?
| | |
| |
| 4.73, Ананимус (?), 19:08, 03/07/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Так есть, 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
Как бы параллельность рулит и педалит .
| | |
|
| 3.53, Аноним (53), 13:31, 03/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
не задумывались о том что если так не сделали до сих пор то это никому не нужно
| | |
| |
| 4.57, Аноним (-), 13:52, 03/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
Задумывался, и поэтому я рылся в issues uutils, и нарыл там обсуждение этой идеи. Это было давно, лет пять(?) наверное назад, и разработчики такие "о, да хорошая идея, но... это ж сколько переписывать надо... жаль что нам не пришло это в голову раньше".
| | |
| |
| 5.58, Аноним (-), 13:54, 03/07/2024 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Задумывался, и поэтому я рылся в issues uutils, и нарыл там обсуждение этой идеи. Это было давно, лет пять(?) наверное назад, и разработчики такие "о, да хорошая идея, но... это ж сколько переписывать надо... жаль что нам не пришло это в голову раньше".
Странно. У них первый релиз был в 2020м.
По идее это относительное начало проекта.
Может они хотели поддерживать легаси?
| | |
| 5.66, noc101 (ok), 16:52, 03/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
 ну то есть это никому не нужно!)
Было бы нужно, что то сделали. А так покивали, покивали и дальше пошли.
| | |
|
| 4.74, YetAnotherOnanym (ok), 20:35, 03/07/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Вообще-то - нужно. Критически нужно. Архинужно. Только проблема в том, что скриптом@к@ки не осознают, насколько это нужно.
Выделение отдельно оформленной либы, в которой реализована вся "полезная нагрузка", позволило бы использовать её функциональность в скриптах (на языках, допускающих подключение сторонних .so) без вызова утилиты в дочернем шелле, а это исключило бы целый класс уязвимостей.
| | |
| |
| 5.79, Аноним (-), 06:55, 04/07/2024 [^] [^^] [^^^] [ответить]
| +/– | |
>Выделение отдельно оформленной либы, в которой реализована вся "полезная нагрузка", позволило бы использовать её функциональность в скриптах (на языках, допускающих подключение сторонних .so) без вызова утилиты в дочернем шелле, а это исключило бы целый класс уязвимостей.
Экосистема GNU/Linux всегда так работает. С разморозкой тебя.
| | |
| 5.84, Аноним (84), 18:02, 08/07/2024 [^] [^^] [^^^] [ответить]
| +/– | |
написать рекурсивный/не рекурсивный обработчик файлов - 20 мин времени на любом языке, прочитать на гитхабе овервью для парочки альтернатив дольше будет.
писать универсальную либу - это колхозить какой-то аналог sql или nosql и конечно же find без grep это полумера, в результате получится комбайн для которого надо будет писать огромный туториал, и чего ради?
В абсолютном большенстве кейсов рекурсивный обход не нужен, а даже если нужен, надо четко понимать что и как обрабатывать, обычно это просто отдельная задача - убрать дубликаты, битые файлы, и прочий мусор, а вот уже потом делать чтото
| | |
|
|
|
|
| 1.18, wd (?), 12:25, 03/07/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
поиск по xattr бы...
а если бы еще и индексы по ним...
| | |
| |
| 2.77, Аноним (77), 04:28, 04/07/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
О, я давно хочу пропатчить slocate на индексирование xattr. Сколько вы готовы заплатить, чтобы я наконец этим занялся?
| | |
|
| 1.27, Соль земли (?), 12:36, 03/07/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Казалось бы, какое отношение суперполезный xargs имеет к поиску чего-либо? Впрочем find и xargs очень хорошо объединяются, позволяя выполнить команду один раз сразу ко всем найденным файлам.
| | |
| |
| |
| 3.81, Аноним (81), 15:52, 04/07/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Только xargs скорее про параллельное исполнение команд для наборов данных, например, find поставляет список интересующих путей/файлов и xargs их одновременно обрабатывает запуская команды с требуемыми условиями и ограничениями (и findutils такой функциональности не предосталяют, насколько мне известно).
| | |
| 3.83, Ахз (?), 16:37, 05/07/2024 [^] [^^] [^^^] [ответить]
| –2 +/– |
Ага, сразу видно кексперта.
Как у тебя выстраивается команда в своей конструкции знаешь ?
Сначала отработает весь поиск а потом результат пойдет выполнение командой в виде позиционных переменных. И весело получишь too many arguments. Поэтоум единственный правильный вариант вот такой
-print0 | xargs -0 команда
Наберут, блин, по объявлению...
Не, хотя если работать в /home/student_02/, то никогда не столкнешься с подобной проблемой :D
И вопрос со звездочкой, на 5-ку - угадай почему print0, а не просто print ? :D
| | |
| |
| 4.85, Аноним (84), 18:05, 08/07/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Ага, сразу видно кексперта.
find -exec - мне на прошлой недели 6 миллионов файлов обработал из примерно 30, давай расскажи ага
| | |
|
|
|
| 1.76, Аноним (76), 02:32, 04/07/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Поддержка musl это хорошо!
> GNU Test Suite
> BFS Test Suite
Сегодня что-то новое узнал.
| | |
|
