> Но когда она будет нужна, я не смогу использовать find с sql. Мне придётся выёживаться мухой на стекле, чтобы получить csv, который затем можно будет затолкать в sqlite, чтобы затем сделать оттуда выборку.Ключевой вопрос: а когда она будет нужна? Но безусловно, если есть регулярная задача, в которой нужно делать выборку по объектам ФС, да так хитро, что без SQL не обойтись - это повод написать своё, всецело устраивающее решение. Но не тянуть ничем не оправданные во всех прочих случаях костыли в стандартные утилиты.
> Мне не нужен find принимающий на вход sql. Всё что он должен принимать -- это список файлов/директорий, которые выданы ему шеллом.
Конечно, ведь это так эффективно - гонять данные от одного процесса к другому, особенно, когда нет никаких причин сразу не сделать всё во втором процессе.
> По-хорошему, он даже вообще не нужен, потому что это умеет ls, и рекурсивно обходить директории ls тоже умеет. Ещё du умеет обходить рекурсивно. Зачем нужен этот десяток реализаций рекурсивного обхода директорий, когда можно обойтись одним?
Скопипасть или вынеси в библиотеку. Проблема то.
> Да ладно, оверинжиниринг -- это find, в который напихали всё что нужно, всё что не нужно, и ещё немного.
Например, что? --delete? --ls? Ну да, это небольшое пренебрежение идеологией во имя практичности.
Но настолько очевидно нужное и тривиальное, что всерьёз к этому цепляться на мой взгляд - придирки.
find делает, в целом, ровно то, что должен - показывает те объекты дерева ФС, которые удовлетворяют описанным опциями командной строки требованиями.
>> Ей богу, я могу придумать только какую-то оторваную от реальности жесть, чтобы sql в find был оправдан. В обычных задачах пользы от этого не будет.
> Есть две директории, в них много одинаковых файлов, но есть разные, я хочу создать третью директорию как объединение/пересечение/дополнение/любая-другая-операция-над-множествами из этих двух. В идеале даже сделать так, чтобы из одной из первых двух была бы сделана "третья", минимальным копированием файлов, потому что она находится на тормозном внешнем носителе, а файлы довольно большие.
Ну я и говорю: высосанная из пальца жесть. Которую даже ценителям надо делать один раз в жизни.
Конечно, это повод делать из простой и быстрой утилиты комбайн.
> Попробуй сделать это find'ом, и ты быстро придёшь к выводу, что проще использовать ad hoc решения, типа всяких там интересных опций cp, которые позволяют условно копировать файлы. Если конечно в списке опций cp есть набор, позволяющий выполнить нужную тебе операцию над множествами. Или ещё проще даже забить болт, и сделать cp -r dir1/* dir2/, забив на ненужные копирования файлов. Ну будет оно 10-20-30 лишних минут копировать, и чё? Зато не надо 10 минут возиться с сочинением злой командной строки, покуривая между делом маны.
Конечно же я не буду решать эту задачу find'ом. Есть же rsync.
> А если найденные файлы можно скормить языку, который умеет в sql, то... эмм... А нужен ли нам вообще в системе find? Нужен ли нам du? Может там ещё пяток утилит, которые можно выкинуть? И ещё можно будет опции cp прочистить, избавив его от всех этих условных копирований. Оставить только то, что часто используется, и поэтому удобно иметь аббревиатуры,
А с чего ты решил, что твоя конструкция вообще будет эффективнее? Она также обойдёт ВСЕ файлы в директориях и потрогает диск столько же раз.
Замена N маленьких приложений на один комбайн - действие противоположное "юниксвею" по смыслу.
> Задача фильтрации информации -- это вещь, которая нужна везде и постоянно. Вынести её в отдельную утилиту, которая умеет _хорошо_ фильтровать: сам бог велел.
1) Такие утилиты уже есть.
2) Отрывать функционал фильтрации там, где он действительно нужен - вредительство и больше ничего. Наличие ограниченного функционала фильтрации где-то не отменяет утилит из пункта 1.
>>> Если же поисковой синтаксис прибит гвоздями к find, то выбора уже не остаётся.
>> Всё так. Но синтаксис не является признаком "юниксвейности".
> Ой, ну давайте теперь будем жонглировать словами, играя в самую низкопошибную демагогию. Я уже третий? четвёртый? раз объясняю что я имею в виду? Не надо делать вид, что ты до сих пор не понял.
По тексту моих ответов ты мог бы и сообразить, что я тебя понял.
Только я продолжаю утверждать, что то, чего хочешь ты не имеет отношения к "unix way".
PS: Идеология должна служить коллективу, а не коллектив идеологии. Иначе это уже тоталитарная секта, а не коллектив.
