Организация локального поиска файлов через locate — дешево и сердито

2017-02-10

В командной строке есть утилита locate, которая ежедневно сканирует файловую систему с помощью утилиты updatedb и позволяет быстро находить файлы на диске по названию. Мне часто удобнее искать не по всему диску, а только по домашней директории или вообще по каким-то отдельным папкам. Обычно я использую find, но, читая man updatedb я обнаружил что поиск можно организовать в локальную базу таким вот образом:

updatedb -l 0 -o db_file -U source_directory

db_file — куда сохранять, source_directory — что сканировать.

Захотелось сделать свой локальный кэшируемый поисковик. Задача — сканировать домашнюю папку /home/vik, кэш хранить в /home/vik/.local/share/mlocate.db (еще одна полезная папка — ~/.local) и иметь возможность задать не locate а «local locate» — llocate.

Сделал отдельный скрипт на сканирование диска:

~/bin/locate/local_updatedb

С содержимым:

#!/bin/sh
updatedb -l 0 -o /home/vik/.local/share/locate.db -U /home/vik -n ".git .bzr .hg .svn .dropbox.cache"

Расшифровка ключей:

-l 0 не проверять права на доступ к базе данных

-o — где сохранить базу данных

-U — что сканировать

-n — какие имена игнорировать (очень удобно, чтобы не получать в поиске имен из папок контроля версий).

Дал скрипту права на запуск:

$ chmode a+x ~/bin/locate/local_updatedb

Обновлялку вынес в крон:

$ crontab -e

и вписал в файл:

@reboot /home/vik/bin/locate/local_updatedb 

«на каждой перезагрузке запускать сканирование диска»

Внимание: если вы редактируете crontab-файл — в конце нужно обязательно оставить пустую строку — иначе не заработает.

Последний штрих — добавил alias llocate в ~/.bash_aliases

alias llocate='locate -d /home/vik/.local/share/mlocate.db'

Пример:

vik@firefly:~$ llocate Войников

/home/vik/av/mp3/Виктор Войников - Честный стрелок.mp3
/home/vik/av/mp3/1_сборки/pulsar/Модель Для Сборки - Виктор Войников - Резонанс.mp3
/home/vik/book/hub/одессика/1914_Вся Одесса_Войников_737.png
...
/home/vik/zbox/yandex/Яндекс.Фотки/memorial Войников_new.jpeg.jpg

«Маскарад в красном смещении»

2016-04-23

Леди coala-the-bear на днях упомянула f.lux и то, что подкрашивание монитора в красные цвета (и уборка синего спектра) хорошо влияет на сон. Для меня, как для совы-заполуношника это зело актуально. Но f.lux проприетарная и под linux работает не ахти, посему озаботился поиском подходящего свободного софта. Причем как на десктоп, так и на андроид, с которого я ночью читаю и на котором у меня стоит dimmer который хорош, но недостаточно.

Быстро выяснилось, что для андроида есть не менее свободный Red Moon, который более чем хорошо справляется со своими задачами. При этом нужно учитывать, что пока он работает не получится устанавливать apk-файлы — собственно, как я понимаю это верно для всех экранных фильтров. Поэтому сначала отключить, а потом обновлять софт.

Для десктопа есть redshift который работает аналогично. gtk-версия у меня не запустилась, поэтому я просто использую коммандлайновый вариант, запуская его из комстроки, через меню или на старте через ~/.config/openbox/autostart.sh и при необходимости убивая через killall redshift. Утилита хорошая, единственное что я бы советовал сделать — сразу положить в ~/.config/ файл redshift.conf (пример есть на сайте) с забитыми в него координатами и режимом manual.


FBReader — чтение и допиливание

2015-07-05

Некоторое время назад перешел с CoolReader на FBReader — польстившись главным образом на сетевую систему синхронизации (которая до сих пор работает у них с каким-то скрипом). В принципе помимо системы синхронизации выяснилось, что FB за прошедшее время допилен до вменяемого состояния, в то время, как CoolReader практически не обновляется — поэтому, оставив обе программы, сейчас пользуюсь FB.

Неудобств у этой софтины пока всплыло два.

Первое — она категорически не хочет открывать .fb2.zip файлы, считая их прерогативой CoolReader. К счастью, есть человек, который не поленился сделать костыль к этому, что сильно облегчило работу с системой.

Второе — скачивая книги из флибусты по OPDS (или вообще из любой сетевой библиотеки), она складывает их в отдельные каталоги не называя по имени-названию, а просто нумеруя.

Скажем Кутузов Лидии Ивченко выкачивается не как Ivchenko_Zhizn-zamechatelnyh-lyudey_1372_Kutuzov.335158.fb2.zip, а как целое дерево вложенных папок: <родная папка fbreader'а>/flibusta.net/b/335158.zip, что ужасно неудобно.

Моя система хранения книг опирается в первую очередь на файловую систему — осмысленные названия файлов и иерархия папок по которым эти файлы тасуются. Ничего более удобного пока нет и, скорее всего, не будет придумано в ближайшее время. Иерархия “папка-файл” выглядит скучновато в отличие от всяческих all-inside хранилищ типа Calibre или той же встроенной библиотеки FBReader, зато надежна, минимальна по занимаемому месту, вообще не требует стороннего софта для упорядочивания, хорошо упорядочивается дельта-итерациями (тема отдельного разговора) и — как я начинаю понимать — нейрологически обоснованна (очень рекомендую такую книгу, как Daniel J. Levitin “The Organized Mind Thinking Straight in the Age of Information Overload” — написано хорошо, не заумно, без утомляющего выпендрежа и по делу).

Поэтому 335158.zip меня не устраивал категорически, хотя сам OPDS-доступ к сетевой библиотеке (т.е. скачивание книги через FBReader) оказался вполне удобным. Первым делом я попробовал переименовывать файлы вручную и раскладывать их по своим папкам — меня хватило файла на два.

К счастью, быстро выяснилось, что внутри у скачанного 335158.zip лежит вполне приличный по названию Ivchenko_Zhizn-zamechatelnyh-lyudey_1372_Kutuzov.335158.fb2 — дальше дело заключалось в написании простенького скрипта:

#!/bin/bash
# основная идея избавиться от закачки безымянных файлов с флибусты

# находит и раззиповывает в корень файлы в каталогах
find . -type f -name "*.fb2.zip" -exec unzip {} \;

Простенький однострочник на самом деле — find спускается вниз по дереву папок, находит файлы (-type f), которые заканчиваются на .fb2.zip (-name "*.fb2.zip") и запускает unzip, который над ними операцию распаковки (-exec unzip {} \; — вместо {} подставляется имя найденного файла). Разумеется, чтобы это работало, в системе должен быть установлен unzip (у меня он стоит по умолчанию — если его нет надо сделать что-нибудь типа sudo apt-get install unzip)

Этот файл (unzipper.sh) был положен в корень (то, что выше названо <родная папка fbreader'а>) и — дррррр! — тридцать файлов, которые к тому времени скопились в дереве папок, оказались найдены, раззипованы и аккуратно сложены в папке со скриптом.

На этом можно было бы остановиться — FBReader в принципе читает и раззипованный .fb2, но почему бы не упаковать все назад в зип? Для этого нужен примерно такой однострочник:

find . -type f -name '*.fb2' -exec zip '{}'.zip '{}' \;

Находим файлы, которые оканчиваются на .fb2 и зипуем их. -exec zip '{}'.zip '{}' \; выполнит операцию zip (он тоже должен быть в системе — sudo apt-get install zip) и подставит в нее найденные название файла ({}) и имя новосоздаваемого архива ({}.zip — старое имя + расширение .zip).

Итого:

#!/bin/bash
# основная идея избавиться от закачки безымянных файлов с флибусты

# находит и раззиповывает в корень файлы в каталогах
find . -type f -name "*.fb2.zip" -exec unzip {} \;

# зипует их обратно
find . -type f -name '*.fb2' -print -exec zip '{}'.zip '{}' \;

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


Чтение электронных книг — 2.5

2015-02-19

или «Dropsync не нужен»

В предыдущей серии ваш покорный слуга описывал свою систему, в которой чтение и архивация небольших заметок (в противовес чтению «больших книг» и книг, сгенерированных из собственных заметок) опирается на .epub и .maff форматы (по сути — зипованные .html) и творческое использование dropbox. Некоторое время назад я отказался от dropsync’а в пользу синхронизации через usb с помощью Unison. Причины, технические подробности, плюсы и минусы перечислены в предыдущей статье.

Вынужденное изгнание и смартфон меняют стереотипы. Смартфон, как «девайс в том числе для чтения» постепенно перетягивает одеяло на себя. Я привык читать с небольших экранов (Palm + WeaselReader), а смартфон (в отличие от более громоздкой читалки) постоянно с собой. Кроме того, появились программы вроде Dimmer’а которые позволяют настраивать яркость и цветовую гамму (например, убирать пресловутый «синий свет») — что сильно сокращает разрыв по разнице в качестве чтения.

Еще у смартфона есть симкарта и (почти всегда) бесплатный gprs-интернет. Сейчас у меня дошли руки до установки dropbox’а (я стараюсь держать на телефоне как можно меньше программ) — и я понял, что мне не нужен не только dropsync (см предыдущую заметку), но скорее всего и синхронизация заметок по шнурку.

На смартфоне интернет есть практически везде и всегда. Epub копеечные по размерам — и даже плохонького gprs вполне хватает для вытягивания файлов «по одному за раз». Прочие операции (удаление-переименование-сортировка) тоже можно делать без доступа ко всему архиву сразу — в самом приложении.
Большие заметки, которые хочется читать в отсутствии сети можно скопировать в отдельную папку, или (сейчас это проще) пометить «звездочкой» — и dropbox будет держать их на диске все время. Получается самое то, при минимальном использовании трафика.


Чтение электронных книг — 2

2014-12-12

В предыдущей заметке о чтении, я разделил свои материалы для чтения на три основные категории: большие книги, мои собственные заметки (в виде Большого Текстового Файла) и «клипы» или «вырезки» — набор разношерстых html-страничек, посты, микротексты, микрозаметки и так далее. Если с большими книгами и большим файлом все было более или менее понятно, то промежуточная категория — заметки, «клипы» и вырезки, была совершенно неопределенной и требовала осмысления.

За прошедший год система чтения изменилась. Многие моменты назрели уже давно, фундаментальным поворотом стал момент, когда я оказался в Метрополии с очень плохим интернетом. Связь через некоторое время наладилась, но момент вынужденной автономности и некоторые исследования, попавшие в мое поле зрения, заставили задуматься.
Читать далее…


Openshot, ImageMagick и красноглазая магия…

2014-11-30

На днях осваивал программу для нелинейного видеомонтажа под Debian GNU Linux. Требовалось смонтировать простенькое слайд-шоу плюс несколько видеофайлов.

Из всех программ выбор пал на OpenShot — как лучший компромисс и аналог Movie Maker’а фирмы M$.

Все хорошо, однако на over 100 фотографиях OpenShot начал тормозить. Непродолжительный поиск подсказал, что проблемой может быть то, что все эти фотки грузятся в трек as is (а там фотографии на десяток мегабайт каждая) и OpenShot’у приходится каждый раз прокручивать все это богатство в памяти.

В теории фотографии можно уменьшить чем-нибудь типа ImageMagick — причем сделать это «одним чохом» в командной строке, но как? То есть я помню что в «Магике» есть утилита convert, но вопрос в том в какой размер конвертировать файлы и как быть с тем, что фотографии в моей подборке разной ориентации?

Ответ нашелся достаточно быстро. Где-то на ЛОРе на аналогичный вопрос советовали использовать связку bash+ffmpeg+imagemagick (что мне не подходило категорически — поскольку подборка требовала еще некоторой подгонки в ручном режиме). После чего я нашел ссылку на скрипт конверсии. Сам скрипт не понадобился — я извлек из него следующие строки:

RESOLUTION=1920x1080
mogrify -resize $RESOLUTION *.JPG

И тупо вбил их в комстроку в моей директории. mogrify — еще одна утилита пакета ImageMagick и она прекрасно справилась с конверсией. Фотографии стали весить порядка пары сотен килобайт, OpenShot перестал тормозить, а клип получился хорошего качества

Разрешение можно было задать и вот так:

mogrify -resize "1920x1080" *.JPG

И скорее всего уменьшить еще. Но это было часа три ночи и для вникания в детали у меня не было настроения.


Система бэкапов mysql moodle на двух машинах через scp ssh

2013-12-27

После вчерашнего танца с бубнами… Гм. Лучше по порядку. Вчера вышел из строя основной сервер. Я запустил резервный сервер, перекинул коммутацию интернетов в обход сервера. Этим я обеспечил интернеты. Потом поднял из бэкапов мудл, который у нас основным рабочим продуктом.

В более-менее спокойной обстановке народ разобрался с основным сервером (повезло — там была мелочь) и буквально через полчаса мы включили все обратно по основной схеме.

Все хорошо. Но. Я понял, что на сервере до сих пор крутится наколенная система бэкапов, которую я запустил полтора года назад. Да, я не сисадмин и вообще это не мой фронт работ, но если не я то, кто — и дальше следуют стандартные оправдания и дисклэймеры.

Из всего, что необходимо для работы мудла самую большую ценность представляет его база данных. Все прочее развертывается и ставится по отработанной схеме. А вот в MySQL хранятся все результаты, опросы и так далее. Читать далее…


%d такие блоггеры, как: