![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Я таки собрался сделать из passkey-agent.c из examples к bluez нечто с более-менее вменяемым интерфейсом. Чтобы сначала рассказывала что за устройство pairing запрашивает (причем не только адрес, но и имя), а потом просила ввести PIN. Естественно, вписать туда setvbuf(stdout,NULL,_IONBF,0) и то же самое для stdin не забыл. А то многие о таких вещах забывают и через пару пайпов с их программой не поработаешь.
Что характерно, родные примеры на питоне на http://wiki.bluez.org имя устройства показывать не умеют. А моё - умеет. Правда, имя оно запрашивает не через DBUS, а через libbluetooth на низком уровне. Потому что это проще.
А если человеку нужен bluetooth passkey agent, то libbluetooth в системе заведомо есть.
Теперь можно писать passkey-агенты на любых скриптовых языках, независимо от наличия биндинга к D-BUS. Ибо аналоги popen и управление буферизацией есть везде.
Теперь бы еще с obexpushd разобраться. А то он только в версии 0.6 научился отдавать скрипту адрес устройства, откуда прислали файл. (а про имя в changelog ни слова). А в etch версия 0.4.
Да, если кто еще не знает, где берут мои debian-овские пакеты:
Что характерно, родные примеры на питоне на http://wiki.bluez.org имя устройства показывать не умеют. А моё - умеет. Правда, имя оно запрашивает не через DBUS, а через libbluetooth на низком уровне. Потому что это проще.
А если человеку нужен bluetooth passkey agent, то libbluetooth в системе заведомо есть.
Теперь можно писать passkey-агенты на любых скриптовых языках, независимо от наличия биндинга к D-BUS. Ибо аналоги popen и управление буферизацией есть везде.
Теперь бы еще с obexpushd разобраться. А то он только в версии 0.6 научился отдавать скрипту адрес устройства, откуда прислали файл. (а про имя в changelog ни слова). А в etch версия 0.4.
Да, если кто еще не знает, где берут мои debian-овские пакеты:
deb http://ftp.wagner.pp.ru/pub/debian-cosy etch local updates tcl