Curiouser and curiouser!
Про это немало “сказов сказано”, но ничего внятного я в итоге не нашел. Много отсылок к использованию decode/encode, парадигмы utf8 и черти чего еще. И не работает.
В зависимоcти от конкретного скрипта решает одна или две строчки:
binmode STDIN, “:utf8″;
binmode STDOUT, “:utf8″;
Все. Теперь с STDIN скрипт принимает русский, в jabber я получаю тоже русский.
Permalink Comments off
Когда много работаешь с опенсурсным софтом, зачастую поневоле, а где-то из интереса, (не*)много узнаешь из смежных нужной тебе области. В том числе, часто и из программирования. На перле я уже сравнительно давно делаю разные скрипты для административной работы, когда возможности шелла не то чтобы исчерпаны, но когда нужен более высокий уровень абстракций. И на перле это реализовать гораздо проще. С C/C++ все гораздо сложнее, особенно в случае если и склад ума не пограммерский (в хорошем смысле этого слова) и база знаний безмерно мала - это про меня. Все-таки для того, чтобы писать на перле, как и на баше, зачастую достаточно где-то подглядеть примеры и, так сказать, начиная с малого, втягиваешься в процесс, по мере необходимого заглядывая в маны. А для Си нужно все-таки довольно плотное изучение.
Сейчас обдумываю и местами воплощаю различные улучшения своей почтовой системы. В том числе мысли занимает и то, какое хранилище
использовать с postfix/dovecot для виртуальных аккаунтов/доменов/алиасов.
Список поддерживаемых баз довольно внушительный у обоих. Есть и места пересечения. Pgsql/Mysql/Ldap например.
C самого mysql все-таки надо слезать, так как показала моя небольшая практика, дополнительный демон здесь лишнее уязвимое звено.
Пару раз он падал по сторонним причинам и почта вставала. Да и хотелось бы что-нибудь полегче. Pgsql и Ldap вобщем-то не подходят по тем же причинам, плюс, несмотря на предпологаемую
легковестность решения на основе Ldap, сам он, имхо, требует немало телодвижений для освоения, а демон в итоге остается. В процессе поисков нашел, что dovecot обладает встроенной поддержкой sqlite, а к
postfix ее можно прикрутить при помощи стороннего патча (postfix_sqlite.patch), который, судя по одному из тредов в мейллистах postfix-users, имеет и шансы попасть в мейнстрим. Если у автора будет достаточно времени, чтобы привести документацию в некий порядок, а вернее ее написать, а также устранить некоторые недочеты. Отсутствие необходимости держать
в этом случае еще одного демона, а также скорость на более простых
выборках, нежели у mysql остановили мой выбор на нем. Хотя бы для
начала “на посмотреть”.
Стал пересобирать postfix по спек файлу с необходимыми изменениями и… обломс. Не выходит у Данилы каменный цеток. В процессе компиляции
отваливается с ошибкой
../../lib/libglobal.a(dict_sqlite.o): In function `dict_sqlite_lookup’:
/usr/src/redhat/BUILD/postfix-2.5.0/src/global/dict_sqlite.c:171:
undefined reference to `sqlite3_prepare_v2′
Взгляд девелопера/программиста, возможно, в общих чертах или даже
сразу понял в чем дело. Это был не мой взгляд 
еще раз перепроверил, что устновленно в системе:
# rpm -qa | grep sqlite
sqlite-devel-3.3.6-2
sqlite-3.3.6-2
python-sqlite-1.1.7-1.2.1
На месте. Опции сборки:
%if %{SQLITE}
CCARGS=”${CCARGS} -DHAS_SQLITE -I/usr/include ”
AUXLIBS=”${AUXLIBS} -L/usr/lib -lsqlite3 ”
%endif
Тоже все на месте. Гугл по вопросу не то, чтобы молчит, но и не говорит ничего определенного. Только в одном месте “глаза споткнулись” об
“checking for SQLITE… yes
checking for sqlite3_table_column_metadata in -lsqlite3… no
Installed SQLite was not compiled with the SQLITE_ENABLE_COLUMN_METADATA,
using embedded SQLite”.
Вероятно где-то это дало внутренний ход работы мозгу. Но решение, да и суть проблемы пока ускользали.
Что делать, когда нужно, а не выходит? Если без виагры, то писать автору патча. После некоторых телодвижений, грепа, просмотра списка rpm пакетов, пары хождений в процессе рабочего дня на сайт sqlite.org я так и сделал. В процессе написания подбил инфу, что установлено, какая система и т.д.
И после отправки письма мысль зашевилилась дальше:
# strings /usr/lib/libsqlite3.so | grep prepare
sqlite3_prepare
sqlite3_prepare16
# grep prepare /usr/include/sqlite3.h | grep int
int sqlite3_prepare(
int sqlite3_prepare16(
…
После этого и еще одного похода на сайт sqlite.org в раздел документации
все стало ясно. В данной версии просто нет необходимой функции, используемой автором. Справедливости ради должен сказать, что здесь http://www.sqlite.org/capi3ref.html#sqlite3_prepare
я не нашел описания, в каких версиях какие функции были добавлены. Совсем не http://dev.mysql.com, где это есть для функций пользовательских, может и что-такое тоже расписано.
Наверное это нужно искать в чейнжлогах. Плюс, отсутствие какой-либо документации к патчу. Это же опенсурс Есть нужно - сам найдешь/сделаешь/поправишь. Дальше было еще одно письмо автору
(не дожидаясь ответа на первое) с вопросом “can function be safely replaced with sqlite3_prepare or sqlite3_prepare16?”
и опять же, просмотр документации вкупе с самим патчем.
Аргументы, согласно документации у обоих функций одинаковый
и у sqlite3_prepare и у sqlite3_prepare_v2, а сама функция используется один раз. Как же тут не попробовать. Процесс компиляции прошел успешно.
Остальное - посмотрим. Opensource, однако.