Файлы с фото: упорядочиваем имена

Недавно вернулся из поездки, притащил оттуда фотки аж на трёх фотоаппаратах. Так уж получилось: Honor 8 Pro хорошо умеет делать фотографии в условиях низкой освещенности и на него можно сделать селфи, Note 4 поражает четкостью и насыщенностью в нормальных условиях, но на него селфи не сделаешь (попала пыль в переднюю камеру), а Canon EOS 1100D и вовсе не телефон, а полноценная камера, хоть и старенькая, но как минимум с оптическим зумом.

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

В итоге, скачанные c одной камеры файлы называются датой-временем, типа 20170830_121103.jpg, на другой - тоже самое, но с неотключаемым префиксом IMG_20170830_121103.jpg, а Canon и вовсе лепит снимки с номерами по возрастанию: IMG_5678.JPG. Как их теперь объединить в один упорядоченный по имени файловый массив, да еще и соблюсти хронологию?!... Ах да, дополнительая беда: перед съемкой я совершенно позабыл выставить на них одинаковое время... 

Ругать кроме себя некого, но можно все-таки попробовать разобраться. Мне помогла замечательная утилита exiftool из пакета libimage-exiftool-perl. Она умеет читать EXIF-информацию из файла (не только из картинок, кстати) и производить над ней несложные, но чертовски востребованные мной операции. Используем её, чтобы получить все файлы с именами типа 20170830_121103.jpg.

Итак, среди двух страниц разнообразных тегов нам нужен только CreateDate, его можно получить так:

$ exiftool -CreateDate IMG_5555.JPG
Create Date                     : 2017:09:03 15:20:01

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

$ exiftool -CreateDate -d "%Y%m%d_%H%M%S.jpg" IMG_5555.JPG 
Create Date                     : 20170903_152001.jpg

Разобьем строку на два поля по двоеточию, возьмем второе и срежем первый символ:

$ exiftool -CreateDate -d "%Y%m%d_%H%M%S.jpg" IMG_5555.JPG | awk -F':' '{print substr($2,2)}'
20170903_152001.jpg

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

Не отчаиваемся! Выбираем одну из камер, которая будет "эталоном". Берем вторую, наблюдаем разницу во времени, хоть с точностью до секунды (но обычно это минуты или даже часы, из-за разных таймзон). Пусть это будет 24 минуты, например. 

Используем опцию exiftool -globalTimeShift, указывая аргументом ей это самое смещение (знак впереди указывает в каком направлении надо сдвинуть временную метку). И натравливаем нижеприводимый скрипт на файлы этой камеры:

#!/bin/bash

for fname in *.JPG; do
  newname=$(exiftool -CreateDate -globalTimeShift "+0:0:0 0:24:0" -d "%Y%m%d_%H%M%S.jpg" $fname | awk -F':' '{print substr($2,2)}')
  mv "$fname" "$newname"
done

Если камер несколько, вычисляем для каждой из них свое смещение от "эталонной", меняем в скрипте зачение аргумента -globalTimeShift и натравливаем на файлы с фотографиями.

Ура, готово! Теперь все файлы называются единообразно, упорядочены по времени, и только внутри у них в EXIF по-прежнему сохранено исходное значение.

В моем случае это не важно, но если нужно, то всемогущий exiftool может и это исправить тоже. 

man exiftool ;)

RSS вместо почты

На работе возникла одна забавная задача, связанная с техподдержкой: исторически, предупреждения разного характера отсылаются по мылу, но не всякий заказчик хочет организовывать хождение почты (а заказчик всегда прав).

Получается, что система уведомлений мягко повисает в воздухе, потому что честно сгенерированные ей предупреждения... просто никуда не отсылаются. Однако, есть log-файл, есть доступ через VPN. Следовательно, информация все-таки доступна, просто надо ей грамотно ей распорядиться!

Решение пришло как-то само собой - откачивать логи, элементарно парсить и отдавать наружу RSS-лентой. Нововведение с RSS населению понравилось ;) Честно говоря, я готовился к смертельной схватке с ретроградами, но обошлось (хотя и пришлось провести ликбез по общению с liferea).

Ингридиенты: postgresql, perl (5.8), libdbi-perl, libdbd-pg-perl, libxml-rss-perl, liferea (у клиента). Написание двух скриптов (один - зкаладка в базу логов, другой - отдача по RSS) заняла в неспешном режиме 2 рабочих дня, шлифовка - еще 3 дня. В принципе, я доволен, потому что получилось просто, а я люблю простые решения...

Perl на N810

Secondly, there is no Perl in the system. It has been left out from the standard maemo environment to save space but can be installed separately by the user.

Отсюда.

Простите, а кто тогда мне пишет на perl --version:

This is perl, v5.8.3 built for arm-linux-gnueabi-thread-multi

BusyBox, что ли?!...

Swig It!

Продолжаем пытки хостинга, теперь нужно исхитриться и подключить c++ - либу к Perl. Делается это, конечно же, при помощи swig. К сожалению, на хостинге я его найти не смог, пришлось качать и ставить самому

Вкратце:

• качаем wget-ом исходники в ~/distro,
  
• tar -xzf tarball.tar.gz -C ~/usr/local
  
• cd ~/src/swig-xxx и ./configure --prefix ~/usr/local
• make install
• export PATH=$PATH:/home/user1234/usr/local/bin

Внятно что-то сделать удалось только с версией 1.3.33, с ней дальше и экспериментировал.

Некоторое удивление я испытал, запуская в домашнем каталоге make. Иногда он мне отвечает Permission denied. Перавя и естественная реакция - ls -la /usr/bin/make, дабы увидеть, что воистину +x. Потом начинаю перебирать дебаговые ключи -v, -dA: с каким-то из них make запускается. Понять, почему иногда я вижу Permission denied, не смог (где же ты, strace?).

Важные узелки на память:

• компилировать C с ключем -fPIC
• для создания .so использовать g++ -shared -o desination.so
• при запуске LD_LIBRARY_PATH должен указывать туда, где лежит .so

Запустить скрипт Perl или умереть

Решил наконец решить задачу подсчета и проверки контрольных сумм файлов, входящих в наш дистрибутив. Типа контроль целостности инсталляции. Работа заняла около 15 минут чистого времени (Perl, при наличии Digest::MD5 - все тривиально, сами понимаете).

И тут я задумался: как же все это будет запускаться на машине клиента, под Windows, где Perl-а и нет в помине?! Лицензия ActivePerl запрещает распространять его дистрибутив, да если даже это и делать - из пушки по муравьям (с). И начал я искать способ конвертнуть Perl-скрипт в .exe.

Как ни странно, в теории оказалось есть несколько способов:

• Perl2exe
• PAR
• PerlApp

В итоге... PerlApp - платный, надо качать PerlStudio PRO, крякать и т.п. Ну никак не соответствует духу свободного ПО. Perl2exe - мало того, что платный, так и еще и требует положить дохрена dll-ек из дистрибутива к себе (утомительная итерационная игра с сомнительным результатом). А PAR для ActivePerl не возможен - судя по странице успешных компиляций содержимого CPAN, pp просто не поддерживается на Windows, т.к. в этой сточке горит веселая надпись "failed". Что-то мне кажется, ActiveState лукавит: ну кто станет поддерживать бесплатное решение, которое конкурирует с их же собственным платным?!..

Короче... Решил все на С написать! Кстати, в рекомендации rfc1321 и исходничек есть. Правда, особенно разбираться, как правильно подключать C-исходник к C++ в MSVC я не стал, поправил md5.h по своему разумению.

А правильнее все-таки было бы с Perl-ом...

Многоязычность в TWiki

Я использую ForUserLanguagesPlugin, который позволяет на одной странице держать и оригинальный текст, и переводы. Именно из-за этого я его и взял на вооружение, на мой вкус одна страница удобнее 10-ти, когда вносишь изменения оригинал и перевод перед глазами одновременно. Да, еще не надо дублировать всякие элементы, если они перевода не требуют (например, фото какого-нибудь hardware-оборудования).

Плугин довольно примитивен, и там есть пара недочетов. Первый - не работает инсталляционный скрипт. С этим все просто - руками рассовываем файлы по каталогам, ставим пермишены. Вторая проблема посложнее: при выборе языка плугин опирается на переменную LANGUAGE, которая сохраняется в сессии. В отсутствие таковой будет установлен дефолтовый английский (lib/TWiki/Plugins/ForUserLanguagesPlugin.pm, sub initPlugin):

$ul = TWiki::Func::getSessionValue( 'LANGUAGE' ) || 'en';

Но ведь хочется-то, чтобы было сразу на том языке, который нам понятен! Представьте себе ситуацию: заходите вы на wiki, там все по-анлгицки. Но справа вверху язык уже выбран - русский! Для того, чтобы получить русский вывод от этого плагина, надо переключиться на любой другой язык и обратно. Толко тогда getSessionValue( 'LANGUAGE' ) вернет 'ru'.

И я задумался, как это сделать без промежуточной переадресации, поскольку что-то менять в TWiki-скриптах меня пугало. Я подумал, что логичнее всего прислушаться к браузеру (так делает и сам TWiki, когда выбирает язык интерфейса пользователя) и вот, что в итоге получилось:

my $lang_det = TWiki::Func::getSessionValue( 'LANGUAGE' );

unless ($lang_det) {
my $accept_language = $ENV{HTTP_ACCEPT_LANGUAGE};

if ( $accept_language =~ /^\w+$/ ) {
$lang_det = $accept_language;
}
if ( $accept_language =~ /^\*$/ ) {
$lang_det = 'en';
}
if ( $accept_language =~ /,/ ) {
($lang_det) = $accept_language =~ /^(\w+?)/;
}
unless ($lang_det) {
$lang_det = 'en';
}
}

$ul = $lang_det;

Конечно, это далеко от совершенства, но работает для MSIE7, Netscape Navigator 9, Firefox 2, Mozilla 1.7.x. Ну и если будете совершенствовать, загляните в RFC2616 :)

Презентации

Полез смотреть API к DBI, напоролся на презентацию для M$ PPT по поводу работы DBI/DBD.

Испытал культурный шок по этому поводу. Однако...

nmake && LWP && Perl

Решил по приколу поставить LWP. Набрал

perl -MCPAN -e 'install Bundle::LWP'

Оно потащило с собой все зависимые пакеты до кучи, многократно обламываясь по самым различным поводам. Сейчас наблюдаю надпись

The required 'nmake' executable not found, fetching it...
Fetching 'Nmake15.exe' from download.microsoft.com... done!
Checking if your kit is complete...
Looks good

Сижу и тихо молюсь... Оно уже дошло до стадии утаскивания perl-5.8.7.tar.gz, как это заведется под моими несчастными виндами, неизвестно...