Tere Habr!
Minu jaoks on see fraas sarnane teremaailmaga, kuna jõudsin lõpuks oma esimese väljaandeni. Lükkasin selle imelise hetke kaua edasi, kuna polnud millestki kirjutada, samuti ei tahtnud ma imeda midagi, mida oli juba mitu korda imetud. Üldiselt soovisin oma esimeseks publikatsiooniks midagi originaalset, teistele kasulikku ning mis sisaldab väljakutset ja probleemide lahendamist. Ja nüüd võin seda jagada. Räägime nüüd kõigest järjekorras.
Kanne
Kõik sai alguse sellest, et mõni aeg tagasi laadisin oma tööarvutisse Linux Mint. Paljud ilmselt teavad, et Sipe pluginaga Pidgin on täiesti sobiv asendus Microsoft Lyncile (praegu nimega Skype for business) Linuxi süsteemidele. Tulenevalt töö spetsiifikast tuleb mul sageli osaleda SIP konverentsidel ja kui olin Windowsi töötaja, oli konverentsidele sisenemine elementaarne: saame kutse posti teel, vajutame sisselogimise lingile ja olemegi valmis minema. .
Linuxi varjuküljele üle minnes muutus kõik mõnevõrra keerulisemaks: loomulikult saab konverentsidesse sisse logida ka Pidginis, kuid selleks tuleb valida SIP konto atribuutide menüüst suvand liituda konverentsiga ning avanevas aknas sisestage konverentsi link või sisestage korraldaja nimi ja conf id. Ja mõne aja pärast hakkasin mõtlema: "kas seda on võimalik kuidagi lihtsustada?" Jah, võite öelda, miks kurat teil seda vaja on? Ma eelistan istuda Windowsis ja mitte räsida.
1. samm: uurimine
"Kui teil tuleb mingi kapriis pähe, ei saa te seda vaiaga välja lüüa," ütles Nekrasov oma teoses "Kes elab hästi Venemaal".
Nii et kui mõte kord pähe sai, tekkis mõne aja pärast esimene idee teostuseks. Kõik tundus lihtne - peate juurdepääsu linkidele pealtkuulama — installige oma autosse kohaliku veebirakenduse protsess aadressil 127.0.0.1 ja failis /etc/hosts lisage ettevõtte domeeni staatiline kirje, mille kaudu konverentsile sisenete, osutades kohalikule hostile. Järgmiseks peab see veebiserver töötlema selle juurde tulnud linki ja selle kuidagi Pidgini sees üle kandma (ütlen kohe, et selles etapis polnud mul veel õrna aimugi, kuidas seda talle üldse anda). Lahendus lõhnab muidugi karkude järele, aga me oleme programmeerijad, kargud meid ei hirmuta (pask).
Siis avasin juhuslikult Google Chrome'is kutselingi (ja tavaliselt kasutan alati Mozilla Firefoxi). Ja minu üllatuseks nägi veebileht hoopis teistsugune välja - kasutajaandmete sisestamiseks puudus ankeet ja kohe peale lehele sisenemist tuli taotlus läbi midagi avada. xdg-avatud. Lõbu pärast klõpsan “jah” ja kuvatakse veateade – linki lync15:confjoin?url=https://meet.company.com/user/confid ei saa avada. Hmm. Mis xdg-open see on ja mida see vajab, et sellised lingid avaneksid? Dokumentatsiooni surmajärgne lugemine näitas, et tegemist on GUI-käitlejaga, mis aitab käitada seotud rakendusi kas uri-skeemi protokollide või konkreetsete failitüüpidega. Seosed konfigureeritakse mime-tüüpi kaardistamise kaudu. Seega näeme, et otsime nimega uri-skeemi jaoks sobivat rakendust lync15 ja link edastatakse xdg-openile, mis siis teoreetiliselt peaks selle edastama mõnele seda tüüpi linkide eest vastutavale rakendusele. Mida meie süsteemis muidugi pole. Kui ei, siis mida nad avatud lähtekoodiga maailmas teevad? Täpselt nii, me kirjutame selle ise.
Edasine sukeldumine Linuxi maailma ja eriti graafilise kesta (töölauakeskkond, DE) toimimise uurimisse, muide, mul on Xfce Linux Mintis, näitas, et rakendused ja sellega seotud mime-tüüp kirjutatakse tavaliselt otse otseteefailid laiendiga .desktop. Noh, miks mitte, ma loon lihtsa rakenduse otsetee, mis peaks lihtsalt käivitama bash-skripti ja väljastama sellele edastatud argumendi konsooli, annan ainult otseteefaili enda:
[Desktop Entry]
Name=Lync
Exec=/usr/local/bin/lync.sh %u
Type=Application
Terminal=false
Categories=Network;InstantMessaging;
MimeType=x-scheme-handler/lync15;
Käivitan konsoolist xdg-open, edastades sama lingi, mis tuleb brauserist ja... põmm. Taas öeldakse, et ta ei saa linki töödelda.
Nagu selgub, ei värskendanud ma oma rakendusega seotud mime-tüüpide kataloogi. Seda tehakse lihtsa käsuga:
xdg-mime default lync.desktop x-scheme-handler/lync15
mis lihtsalt redigeerib faili ~/.config/mimeapps.list.
Katse number 2 xdg-open kõnega – ja jälle ebaõnnestumine. Ei midagi, raskused ei hirmuta meid, vaid ainult toidavad meie huvi. Ja olles relvastatud kogu bashi (st jälitamise) võimsusega, sukeldume pea ees silumisse. Siin on oluline märkida, et xdg-open on vaid shelliskript.
bash -x xdg-open $url
Väljundit pärast jälgimist analüüsides saab veidi selgeks, et juhtimine läheb seejärel üle ekso-avatud. Ja see on juba binaarfail ja raskem on mõista, miks see tagastab ebaõnnestunud tagastuskoodi, kui edastab sellele argumendis lingi.
Olles läbi vaadanud xdg-openi sisemised, sain teada, et see analüüsib erinevaid keskkonnaparameetreid ja annab juhtimise edasi kas mõnele konkreetsele DE-le spetsiifiliste faililinkide avamise tööriistadele või on tal varufunktsioon avatud_üldine
open_xfce()
{
if exo-open --help 2>/dev/null 1>&2; then
exo-open "$1"
elif gio help open 2>/dev/null 1>&2; then
gio open "$1"
elif gvfs-open --help 2>/dev/null 1>&2; then
gvfs-open "$1"
else
open_generic "$1"
fi
if [ $? -eq 0 ]; then
exit_success
else
exit_failure_operation_failed
fi
}
Lisan siia kiiresti väikese häkkimise, mis analüüsib läbitud argumendit ja seda, kas meie konkreetne alamstring seal asub lync15:, siis anname juhtimise kohe üle funktsioonile avatud_üldine.
Katse number 3 ja kas see teie arvates töötas? Jah, nüüd, muidugi. Aga veateade on juba muutunud, see on juba progress - nüüd ütles ta mulle, et faili ei leitud ja faili kujul kirjutas mulle, et sama link läks argumendiks.
Seekord osutus see funktsiooniks on_faili_url_või_tee, mis analüüsib sisendile edastatud faililinki: file:// või faili teed või midagi muud. Ja kontroll ei töötanud õigesti, kuna meie eesliide (url-skeem) sisaldab numbreid ja regulaaravaldis kontrollib ainult märgistikku, mis koosneb :alpha: punktidest ja kriipsudest. Pärast rfc3986 standardiga konsulteerimist ühtne ressursi identifikaator Selgus, et Microsoft seekord midagi ei riku (kuigi mul oli selline versioon). Lihtsalt märgiklass :alpha: sisaldab ainult ladina tähestiku tähti. Muudan tavalise kontrolli kiiresti tähtnumbriliseks. Valmis, olete hämmastav, kõik hakkab lõpuks käima, kontroll pärast kõigi kontrollide andmist meie skriptirakendusele, meie link kuvatakse konsoolil, kõik on nii, nagu peab. Pärast seda hakkan kahtlustama, et kõik ekso-openi probleemid tulenevad ka lingivormingu valideerimisest skeemis olevate numbrite tõttu. Hüpoteesi kontrollimiseks muudan rakenduse mime-tüüpi registreerimise lihtsalt skeemiks Lync ja voila – kõik töötab ilma open_xfce funktsiooni alistamata. Kuid see ei aita meid kuidagi, sest konverentsile sisenemise veebileht loob lingi lync15-ga.
Seega on teekonna esimene osa läbitud. Me teame, kuidas lingikõnet pealt kuulata ja siis tuleb seda Pidgini sees kuidagi töödelda ja edastada. Et aru saada, kuidas see menüüs “liitu konverentsiga” lingi kaudu andmete sisestamisel sisemiselt toimib, kloonisin Sipe projekti Git repositooriumi ja valmistusin uuesti koodi sukelduma. Siis aga tõmbasid mind õnneks kataloogis olevad skriptid contrib/dbus/:
- sipe-join-conference-with-uri.pl
- sipe-liitu-konverentsi-ja-id.pl
- sipe-helista-telefoninumber.pl
- SipeHelper.pm
Selgub, et Sipe plugin on suhtlemiseks saadaval läbi dbus (töölaua siini) ja skriptide sees on näiteid konverentsiga liitumisest lingi kaudu, kas korraldaja nime ja conf-id kaudu või saab kõne algatada sip kaudu . See on täpselt see, millest me puudust tundsime.
2. samm. Automaatse ühendamise töötleja juurutamine
Kuna Pearlis on valmis näiteid, siis otsustasin lihtsalt kasutada sipe-join-conference-with-uri.pl ja muutke seda veidi enda jaoks sobivaks. Ma võin kirjutada Pearlis, nii et see ei tekitanud erilisi raskusi.
Pärast skripti eraldi testimist kirjutasin selle kutse faili lync.desktop. Ja see oli võit! Kui sisenete konverentsiga liitumise lehele ja lubate xdg-openil käitada, avaneb Pidgini konverentsi hüpikaken automaatselt. Kuidas ma rõõmustasin.
Edust innustununa otsustasin sama teha oma põhibrauseri Mozilla Firefoxiga. Rebase kaudu sisse logides avaneb autoriseerimise leht ja päris allosas on nupp liituge kontorikommunikaatori abil. Tema oli see, kes mu tähelepanu köitis. Kui klõpsate sellel brauseris, suunatakse see aadressile:
conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}%3Frequired-media=audio
millele ta ütleb mulle lahkelt, et ta ei tea, kuidas seda avada, ja võib-olla pole mul sellise protokolli jaoks seotud rakendust. Noh, me oleme selle juba läbi elanud.
Registreerin kiiresti oma skriptirakenduse ka uri skeemi jaoks conf ja... midagi ei juhtu. Brauser kurdab pidevalt, et pole ühtegi rakendust, mis minu linke käsitleks. Sellisel juhul toimib parameetritega konsoolist xdg-open kutsumine ideaalselt.
„Määra kohandatud protokollikäsitleja Firefoxis” – läksin selle küsimusega võrku. Pärast mitut arutelu stackoverflow teemal (ja kus me oleksime ilma selleta) tundub, et vastus leiti. Peate looma spetsiaalse parameetri about: config (loomulikult asendades foo sõnaga conf):
network.protocol-handler.expose.foo = false
Loome selle, avame lingi ja... pole õnne. Brauser, nagu poleks midagi juhtunud, ütleb, et ta ei tunne meie rakendust.
Ma loen Mozilla protokolli registreerimise ametlikku dokumentatsiooni, gnome'i töölaual on võimalus registreerida seoseid (loomulikult asendades foo conf-iga):
gconftool-2 -s /desktop/gnome/url-handlers/foo/command '/path/to/app %s' --type String
gconftool-2 -s /desktop/gnome/url-handlers/foo/enabled --type Boolean true
Registreerin, avan brauseri... ja jälle habe.
Siin hakkab mulle silma üks rida dokumentatsioonist:
Järgmine kord, kui klõpsate protokolli tüüpi foo lingil, küsitakse teilt, millise rakendusega see avada.
- Semjon Semenõtš
- Ahh
Me ei klõpsa lingil, vaid veebileht lihtsalt muudab javascripti kaudu window.location'i. Kirjutan lihtsa html-faili koos lingiga conf-protokollile, avan selle brauseris, vajutan lingile - Yos! Avaneb aken, kus küsitakse, millises rakenduses peame oma lingi avama, ja seal on meil Lynci rakendus juba loendis - registreerisime selle ausalt kõigil võimalikel viisidel. Seal on aknas märkeruut "jätke valik meelde ja avage alati lingid meie rakenduses", märkige see, klõpsake nuppu OK. Ja see on teine võit – avaneb konverentsiaken. Samas ei toimi konverentside avamine ainult siis, kui klõpsate lingil, vaid ka siis, kui liigute meile vajalikult liitumislehelt konverentsile.
Seejärel kontrollisin, kustutades parameetrid network.protocol-handler.expose.conf ei mõjutanud kuidagi protokolli toimimist Foxis. Lingid töötasid edasi.
Järeldus
Olen kogu oma töö üles laadinud GitHubi hoidlasse; lingid kõikidele ressurssidele on artikli lõpus.
Olen huvitatud tagasiside saamisest neilt, kes soovivad minu tööd kasutada. Pean kohe märkima, et tegin kogu arenduse ainult oma Linux Mint süsteemi jaoks, nii et mõned muud distributsioonid või töölauad ei pruugi selles versioonis töötada. Õigemini, ma olen selles isegi peaaegu kindel, sest parandasin xdg-openis ainult 1 funktsiooni, mis on seotud ainult minu DE-ga. Kui soovite lisada tuge teistele süsteemidele või lauaarvutitele, kirjutage mulle Githubis tõmbetaotlused.
Kogu projekti valmimine võttis aega 1 õhtu.
Lingid:
Allikas: www.habr.com