LINUX.ORG.RU

fselect 0.3.1

 , , , ,


6

4

fselect — это консольная утилита для поиска файлов с помощью выражений, напоминающих SQL. В некоторых случаях может заменить традиционный find.

Преимущества:

  • возможность создания сложных запросов с помощью скобок и операторов SQL;
  • поиск по ширине/высоте изображений;
  • поиск внутри zip-архивов;
  • форматирование вывода в CSV, JSON и null-terminated строки.

Пример:

$ fselect "fsize, modified, path from /home/pupseng depth 3 where size >= 1mb and ( name like '%.jpg' or name like '%.png' )"

1.82 MiB	2018-01-16 13:31:59	/home/pupseng/Pictures/Screenshot from 2018-01-16 13:31:46.png	
1.29 MiB	2017-09-05 13:00:02	/home/pupseng/Downloads/Telegram Desktop/image_2017-09-05_12-59-55.png	
2.74 MiB	2017-05-31 12:23:31	/home/pupseng/Downloads/Telegram Desktop/IMG_9514.jpg	
2.25 MiB	2017-07-28 15:57:44	/home/pupseng/Downloads/Telegram Desktop/image_2017-07-28_15-57-35.png	
3.56 MiB	2016-07-04 16:43:13	/home/pupseng/Downloads/fugue.png	
7.15 MiB	2016-10-24 12:25:32	/home/pupseng/Natasha/DCIM6807.jpg	

Утилита написана на языке программирования Rust и в настоящий момент устанавливается с помощью cargo. Крайне приветствуется помощь в организации сборки пакетов для различных дистрибутивов Linux, а также Mac OS.

>>> Подробности на Github

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

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

hobbit ★★★★★ ()
Ответ на: комментарий от hobbit

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

$ cargo install fselect

pftBest ★★★ ()
Последнее исправление: pftBest (всего исправлений: 2)

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

anonymous ()

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

incker ()
Ответ на: комментарий от MrClon

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

A-234 ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

[test] touch ... ...0
[test] ls -a 
.  ..  ...  ...0
[test] find -name ...
./...
[test] fd -FH ...
...
...0
[test]
LittleBin ()
Ответ на: комментарий от anonymous

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

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

LittleBin ()
Ответ на: комментарий от LittleBin

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

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

anonymous ()
Ответ на: комментарий от dave

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

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

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

upcFrost ★★★★★ ()
Ответ на: комментарий от pftBest

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

upcFrost ★★★★★ ()
Ответ на: комментарий от upcFrost

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

upcFrost ★★★★★ ()
Ответ на: комментарий от A-234

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

MrClon ★★★★★ ()
Ответ на: комментарий от upcFrost

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

dave ★★★★★ ()
Ответ на: комментарий от dave

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

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

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

upcFrost ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

LittleBin ()
Последнее исправление: LittleBin (всего исправлений: 1)

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

system-root ★★★ ()
Ответ на: комментарий от anonymous

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

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

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

upcFrost ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от saahriktu

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

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

Sociopsih ★☆ ()
Ответ на: комментарий от upcFrost

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

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

anonymous ()
Ответ на: комментарий от Jini

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

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

anonymous ()

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

anonymous ()

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

seiken ★★★★ ()
Ответ на: комментарий от seiken

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

anonymous ()

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

dnb ()
Ответ на: комментарий от dnb

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

pftBest ★★★ ()
Ответ на: комментарий от saahriktu

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

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

h578b1bde ★★ ()
Ответ на: комментарий от Bobby_

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

man квоты.

h578b1bde ★★ ()
Ответ на: комментарий от MrClon

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

A-234 ★★★★★ ()
Ответ на: комментарий от A-234

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

MrClon ★★★★★ ()
Ответ на: комментарий от MrClon

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

A-234 ★★★★★ ()
Ответ на: комментарий от A-234

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

MrClon ★★★★★ ()
Ответ на: комментарий от MrClon

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

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

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

A-234 ★★★★★ ()
Ответ на: комментарий от A-234

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

MrClon ★★★★★ ()
Ответ на: комментарий от A-234

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

system-root ★★★ ()
Ответ на: комментарий от MrClon

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

A-234 ★★★★★ ()
Ответ на: комментарий от A-234

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

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

MrClon ★★★★★ ()
Ответ на: комментарий от system-root

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

A-234 ★★★★★ ()
Ответ на: комментарий от A-234

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

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