в настоящий момент устанавливается с помощью cargo.

Это означает, что она устанавливается сборкой из исходников?

Да, но их самому качать не обязательно, cargo умеет по названию пакета качать исходники, собирать их, и ложить бинари в ~/.cargo/bin. Тоесть если компилятор установлен, то нужно только сделать только одну команду:

$ cargo install fselect

просто напросто - ненужно для поиска файлов иди кури sql? а работает небось через тот же find и прочее системное так проще использовать то, что уже много лет используется то, о чём можно найти инфу и на всех языках то, что тупо есть искаропки а для «узких» задач, один пёс писать скрипты, какое-то ПО ну и зачем тогда это? керня, товарищи

редактор здесь, крайне нелогичен неудобен

давайте дауна марка прикрутите

Это же изи и самому написать. Но хорошо что такое есть)

Так это вопрос представления. Понятно, что при иерархическом представлении оно не может быть вполне реляционным, но ведь можно сделать реляционное представление данных ФС.

Кстати, тут есть ещё одна замена find на Rust: https://github.com/sharkdp/fd

Я так понял, что fd не умеет найти файл с именем из трёх точек, не выдавая в аутпут файлы, которые помимо трех точек содержат в имени еще что-то. Если не заметил такой опции, подскажите, пож.

[test] touch ... ...0
[test] ls -a 
.  ..  ...  ...0
[test] find -name ...
./...
[test] fd -FH ...
...
...0
[test]

работает небось через тот же find и прочее системное... и зачем тогда это?

Всё ж наличие классов is_archive, is_audio, is_doc, is_image, is_source, is_video — это хорошо.

Я так понял, что fd не умеет найти файл с именем из трёх точек, не выдавая в аутпут файлы, которые помимо трех точек содержат в имени еще что-то. Если не заметил такой опции, подскажите, пож.

ХЗ, можно отрапортоваться.

Кто кого склонил, и что тогда за билд?

я юзаю для билдов OBS. его большой плюс - он умеет два десятка дистров разом. большой минус - на время билда машинка не имеет доступа в интернет.

до билда можно подготовить исходники через SourceService, в том числе скачать их с гита. но SourceService'ов не так много, и cargo-vendor в их число не входит.

еще есть вариант делать архив с вендорингом из билда тревиса, после чего хуком цеплять его на тот же obs, но это требует доступа к админке репа. либо вообще все на тревисе собирать, но это геморрой, плюс тревис не умеет создавать реп/оверлей/PPA

можно отрапортоваться

done: https://github.com/sharkdp/fd/issues/252

Так исходники можно подготовить и своим простейшим скриптом, который дернул бы оригинальные исходники, замутил вендоринг и скормил все это OBS. Через гит, другой аккаунт на гитхабе, или как-то еще.

Так исходники можно подготовить и своим простейшим скриптом, который дернул бы оригинальные исходники, замутил вендоринг и скормил все это OBS. Через гит, другой аккаунт на гитхабе, или как-то еще.

да, я сейчас примерно это и собираюсь сделать. собственно это и есть те самые лишние телодвижения.

Короче пока буду собирать вот тут

https://build.opensuse.org/package/show/home:upcFrost:rust/fselect

билды для rpm-based готовы, для deb-based будут чуть позже. потом думаю открою Issue на гитхабе прицепить реп

Реляционное представление тем и славно что в него можно более или менее удачно запихать любые данные, хоть ключ-значение, хоть графовые. Но мемкэш и графовые СУБД не становятся от этого реляционными

Да я про русский язык) Просто забавно получилось, что у обычного слова «склонить» (к чему-нибудь, например, к разврату) появилось новое значение. Не знаю, может быть, сейчас так и говорят, но я не слышал до этого

а, блин, и правда. надо ударение было проставить на первый слог

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

склОнить - да, говорят, от «git clone»

Как админ локалхоста, могу сказать, что locate + grep хватит в 99% случаев. В 0.99% открывается double commander и там вводятся все мыслимые и немыслимые шаблоны на поиск и замену. Ну а в оставшихся случаях, можно и мануал по find почитать и освежить в памяти sed.

locate + grep хватит в 99% случаев

locate не годится при частом изменении фс, нужно всё время запускать updatedb, каждый раз задействуя админ. права.

https://build.opensuse.org/package/show/home:upcFrost:rust/fselect

забилдил

cli неюзабельно говно. все эти hsize, fsize, N+1size, is_N+1someshit. в лучших традициях короче.

пару кофе со сливками этому анонимусу!

Ну а в оставшихся случаях, можно и мануал по find почитать и освежить в памяти sed

find, как и большинство гнутых утилит, имеет откровенно наркоманский синтаксис. Но хрен с ним.

Кмк такая утилита, если ее допилить как следует, может быть удобна для комбайнов с SQL-интерфейсом

Без предварительной индексации?

ХЗ, можно отрапортоваться.

Решения, подсказанные разрабом:

fd '^\.\.\.$'
fd '^\.{3}$'
fd '^[.]{3}$'

https://github.com/sharkdp/fd/issues/252

AUR

Может быть кому интересно. Я добавил пакет с fselect в AUR: https://aur.archlinux.org/packages/fselect/

Как можно жить без find'а?

Просто не устраивать срач на компе. Правда, у меня так не получается.

find, как и большинство гнутых утилит, имеет откровенно наркоманский синтаксис.

rtfm, find - вполне себе посикс, в гну наприкручено еще всякого, но изначальный «дизайн» не на их совести

Ну а у меня была. Я храню музыку во flac, а на плеере для экономии места на карточке использую mp3. Когда я скачиваю очередной альбом, я запускаю несколько скриптов, которые переименовывают скачанные файлы в нужном мне формате, расставляют теги, перекодируют в несколько потоков в mp3 и записывают на плеер.

Хранить во флаке, а слушать мп3? «Я покупаю выдержанную говядину на стейк, но для экономии времени ебашу её в микроволновку и обильно заливаю получившееся хрючело маянезиком».

Если не на Qt, то ненужно.

На что только не идут люди, лишь бы не пользоваться PowerShell.

Лично я пойду на многое, чтобы не пользоваться этой вашей Мощной Ракушкой.

А что так?

Детская психотравма

Не совсем понял её назначение. Она может искать файлы по содержимому? Типа grep "Маруся" ./* И в чем её киллер-фича, кроме sql-подобного синтаксиса? Просто если find быстрее, то очевидно что find нужен, а fselect нет.

Померяй, а потом нам расскажешь быстрее или нет.

Например, если нужно изменить размеры 87519-ти jpeg'ов, то они открывают по одному файлу в GIMP'е.

Пока линуксоиды сношаются, открывая 87519 жпегов в гимпе, виндузятники запускают пакетное редактирование в каком-нибудь FastStone и идут сношать женщин.

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

man квоты.

Как так? Представление реляционное но не реляционное. Что именно мешает записям объектов в ФС иметь реляционное представление?

Ещё раз: иерархические данные можно уложить в реляционную базу, но не любые данные которые можно уложить в реляционную базу можно уложить в иерархическую (без потери информации об их взаимной связи, разумеется)

Ну нет, я вам конкретный вопрос задаю а вы мне в общем отвечаете. Иерархическими данными в ФС, для определенности пусть это будет ext2, являются только имена, но поскольку они уникальны то роль первичного ключа напрашивается сама собой, пусть даже в виде одного отношения. Да, мы теряем в явном виде требование иерархичности имен (оно длинно формулируется, если захотите приведу). Я тут вижу другую проблему, та примитивная форма в виде одного отношения не имеет особого смысла, но это не значит что нельзя предложить нечто более интересное.

Ты чего добиться-то хочешь? Загнать файловую систему в РСУБД (это возможно, но ненужно, специализированные решения эффективнее), или заменить РСУБД на файловую систему (в общем случае это невозможно без потерь, во всяком случае без нагромождения костылей)? Или ты просто разводишь флудирастию ради флудирастии?

Полезно не только читать сообщение но и то на что оно отвечает:

Строго говоря файловая система и есть база данных. Но ни разу не реляционная.

Весь спич за то, что ФС сама по себе может быть представлена в виде реляционной БД со всеми вытекающими. А если нет то почему. Вы же развели бодягу вокруг того, что ФС привычно считать иерархической и это не позволяет ее сделать вполне реляционной не приведя ни единого примера почему это так. Если это все на уровне ощущений то ок, так и скажите, вопросов нет.

Ага, как-раз прочитал тред до начала. Слушай, кончай уже тупить. Да, в РСУБД можно положить иерархические данные. В РСУБД можно положить вообще какие хочешь данные, и почти во всех случаях с ними можно будет более-менее вменяемо работать, это главная фишка РСУБД (а вовсе не индексы или SQL). Вот только работать с древовидными данными в РСУБД неудобно, постоянно приходится городить костыли и подпорки.
Стековерфлов завален вопросами новичков впервые столкнувшихся с необходимостью хранить древовидные данные (сложное меню, иерархию рубрик) в РСУБД и более или менее костыльными решениями оправданными по большому счёту только тем что «ну не впиливать-же отдельную СУБД для такой фигни».

никогда о таких вещах не задумывался долго, но сейчас мысленно засунул самую простую структуру в граф и стало понятно, что иерархия вообще не нужна. ну т.е. ноды-директории не имеют никакого смысла при существовании метаданных у нод-файлов.
можно рассуждать на эту тему больше двух минут, но тут встаёт вопрос — если иерархия это атавизм и исторически сложенные ограничения, то нафига такое представлять в виде реляционной БД? это действие не несёт ничего нового и только усложняет старое.

Теперь мне понятно в чем проблема. Иерархичность ФС - понятие весьма условное и первично данные в ФС не иерархичны ни разу. У нас нет отношений типа: изделие->склад->фирма, где объекты на разных уровнях иерархии различаются принципиально и не могут переместиться с одного уровня на другой. Более того, мы вынуждены изобретать такие уродливые понятия как «ссылка» вследствие того, что нуждаемся в разных представлениях одних и тех же данных. Воспринимать ФС как иерархические данные это обманывать самого себя, в действительности это просто одно из возможных представлений.
Хотя ладно, ответ я понял.

Ничего ты не понял, Джон Сноу. «изделие->склад->фирма» это как-раз самое то для реляционной модели. Есть сущности «изделие», «склад» и «фирма» (три таблички) и между этими сущностями есть определённый набор типов связей (внешние ключи). Фирма не может храниться на складе, она может им только владеть. Склад не может находиться в изделии.
В дереве же (в чистом случае) все элементы принадлежат к одному типу и их можно свободно менять местами, ограничения накладываются только на общую топологию связей (запрещена цикличность связей). Хороший пример: сотрудники организации. Все они человеки и в результате различных пертурбаций начальник и подчинённый вполне могут (в теории) поменяться местами. Ну или один из сотрудников отдела может стать руководителем собственного отдела при этом оставшись тем-же индивидом (только с бонусом к ЧСВ :)
Склады и товары хорошо ложатся на РСУБД, на файловую систему (или другую древовидную СУБД) уже не очень (придётся вручную следить за тем чтобы третий склад не оказался внутри пакета чипсов).
Сотрудники компании хорошо ложатся на древовидную СУБД, и более менее ложатся на РСУБД (постольку поскольку внутри неё можно построить дерево, да и вообще на РСУБД можно положить более или менее что угодно).

Ты бы покурил теорию этого дела, раз оно тебе интересно. Кники и курсы по теории и проектированию баз данных есть кажется даже на русском. На Лекториуме помнится что-то такое было, с ходу не вспомню

Я не рассматривал полезность такого представления, я просто предположил что оно имеет право на существование наряду с устоявшимся восприятием ФС как иерархической структуры. Ведь в виде файлов приходится хранить кучу разнородной информации которая может группироваться по самым разным принципам в зависимости от задачи. Например было бы удобно иметь такой инструмент как создание view, что сейчас эмулируется всякими ссылками. Очевидно объекты-файлы имеют разный набор параметров, у картинок есть размер а у аудиофайлов длительность ну и т.д. В общем тема интересная и мне кажется тут есть определенная перспектива для развития.

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

• нет, это не ФС устоялась как иерархическая структура, это привычное представление документооборота докомпьютерной эры засунули в ФС.
• нет, реляционки не имеют право на существование как ФС, это привычное представление «табличного хранилища» засунутое в привычное представление документооборота докомпьютерной эры.
• нет, в виде файлов не хранится различная информация в ФС, там хранятся файлы.
• нет, в реляционки у картинок тоже будет длительность, а у аудиофайлов размер и баланс белого, потому что это реляционки
• и нет, тема не интересная, привычное представление «табличного хранилища» засунутое в привычное представление документооборота докомпьютерной эры _не_ может иметь перспективы развития по дефолту. это как думать о перспективах развития коромысла из наноматериалов, вместо того, чтобы создавать центральное водоснабжение.