Hei Habr!
For meg er denne setningen beslektet med hello world, siden jeg endelig kom til min første publikasjon. Jeg utsatte dette fantastiske øyeblikket lenge, siden det ikke var noe å skrive om, og jeg ville heller ikke suge på noe som allerede hadde blitt sugd på en haug med ganger. Generelt, for min første publikasjon ville jeg ha noe originalt, nyttig for andre og inneholde en slags utfordring og problemløsning. Og nå kan jeg dele dette. La oss nå snakke om alt i orden.
Entry
Det hele startet da jeg for en tid siden lastet ned Linux Mint på arbeidsdatamaskinen min. Mange vet nok at Pidgin med Sipe-plugin er en helt passende erstatning for Microsoft Lync (nå kalt Skype for business) for Linux-systemer. På grunn av spesifikasjonene i arbeidet mitt, må jeg ofte delta i SIP-konferanser, og da jeg var en Windows-arbeider, var det grunnleggende å delta på konferanser: vi mottar en invitasjon per post, klikker på påloggingslenken, og vi er klare til å gå .
Når du byttet til den mørke siden av Linux, ble alt noe mer komplisert: selvfølgelig kan du også logge på konferanser i Pidgin, men for å gjøre dette må du velge bli med i konferansen i menyen i egenskapene til SIP-kontoen din og i vinduet som åpnes, sett inn en lenke til konferansen eller skriv inn navnet på arrangøren og konfid. Og etter en tid begynte jeg å tenke: "er det mulig å forenkle dette på en eller annen måte?" Ja, du kan kanskje si, hvorfor i helvete trenger du dette? Jeg vil heller sitte på Windows og ikke bli forvirret.
Trinn 1: Forskning
"Hvis du får et innfall i hodet ditt, kan du ikke slå det ut med en innsats," sa Nekrasov i sitt verk "Who Lives Well in Rus."
Så når tanken kom inn i hodet mitt, oppsto den første ideen for implementering etter en stund. Alt virket enkelt - du må avskjære tilgang til lenker — installer en lokal webapplikasjonsprosess på bilen din på 127.0.0.1 og i /etc/hosts legg til en statisk oppføring for firmadomenet du går inn i konferansen gjennom, og peker til localhost. Deretter må denne webserveren behandle koblingen som kom til den og på en eller annen måte overføre den inne i Pidgin (jeg vil si med en gang at på dette stadiet hadde jeg fortsatt ingen anelse om hvordan jeg skulle gi den til den i det hele tatt). Løsningen lukter selvfølgelig krykker, men vi er programmerere, krykker skremmer oss ikke (shit).
Så, ved en tilfeldighet, åpnet jeg på en eller annen måte invitasjonslenken i Google Chrome (og vanligvis bruker jeg alltid Mozilla Firefox). Og til min overraskelse så nettsiden helt annerledes ut - det fantes ikke noe skjema for å legge inn brukerdata og umiddelbart etter å ha kommet inn på siden kom det en forespørsel om å åpne noe gjennom XDG-open. Bare for moro skyld klikker jeg "ja" og en feilmelding vises - lenken lync15:confjoin?url=https://meet.company.com/user/confid kan ikke åpnes. Hmm. Hva slags xdg-open er dette og hva trenger den for at slike lenker skal åpne? En post mortem-lesing av dokumentasjonen viste at det er en GUI-behandler som hjelper til med å kjøre tilknyttede applikasjoner enten med protokoller for uri-skjemaet eller med spesifikke filtyper. Tilknytninger konfigureres via mime-type kartlegging. Så vi ser at vi kjører et søk etter en matchet applikasjon for en uri-ordning med navn lync15 og lenken sendes til xdg-open, som da, i teorien, skal sende den til en applikasjon som er ansvarlig for denne typen lenker. Noe vi selvfølgelig ikke har i systemet vårt. Hvis ikke, hva gjør de i open source-verdenen? Det stemmer, vi skriver det selv.
Ytterligere fordypning i Linux-verdenen og spesielt i å studere hvordan det grafiske skallet (skrivebordsmiljø, DE) fungerer, forresten, jeg har Xfce i Linux Mint, viste at applikasjoner og mime-typen assosiert med det vanligvis skrives direkte i snarveisfiler med filtypen .desktop. Vel, hvorfor ikke, jeg lager en enkel applikasjonssnarvei, som ganske enkelt skal starte et bash-skript og sende ut argumentet som er sendt til det til konsollen, jeg gir bare selve snarveisfilen:
[Desktop Entry]
Name=Lync
Exec=/usr/local/bin/lync.sh %u
Type=Application
Terminal=false
Categories=Network;InstantMessaging;
MimeType=x-scheme-handler/lync15;
Jeg starter xdg-open fra konsollen, og sender den samme lenken som kommer fra nettleseren og... bummer. Igjen står det at den ikke kan behandle koblingen.
Som det viser seg, oppdaterte jeg ikke katalogen med tilknyttede mime-typer med applikasjonen min. Dette gjøres med en enkel kommando:
xdg-mime default lync.desktop x-scheme-handler/lync15
som ganske enkelt redigerer filen ~/.config/mimeapps.list.
Forsøk nummer 2 med xdg-open call - og igjen feil. Ingenting, vanskeligheter skremmer oss ikke, men gir bare næring til vår interesse. Og bevæpnet med all kraften til bash (dvs. sporing), dykker vi med hodet først inn i feilsøking. Det er viktig å merke seg her at xdg-open bare er et skallskript.
bash -x xdg-open $url
Ved å analysere utgangen etter sporing blir det litt tydelig at kontrollen deretter overføres til exo-åpent. Og dette er allerede en binær fil, og det er vanskeligere å forstå hvorfor den returnerer en mislykket returkode når den sender en lenke til den i et argument.
Etter å ha sett gjennom det indre av xdg-open, fant jeg ut at det analyserer ulike miljøparametere og sender kontrollen videre enten til noen verktøy for å åpne fillenker som er spesifikke for en bestemt DE, eller den har en reservefunksjon åpen_generisk
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
}
Jeg vil raskt legge inn her et lite hack med analyse av det beståtte argumentet og om vår spesifikke understreng er plassert der lync15:, så overfører vi umiddelbart kontrollen til funksjonen åpen_generisk.
Forsøk nummer 3 og tror du det fungerte? Ja, nå, selvfølgelig. Men feilmeldingen har allerede endret seg, dette er allerede fremgang - nå fortalte han meg at filen ikke ble funnet, og i form av en fil skrev han meg den samme lenken som ble sendt som et argument.
Denne gangen viste det seg å være en funksjon is_file_url_or_path, som analyserer fillenken som sendes til inngangen: file:// eller banen til filen eller noe annet. Og sjekken fungerte ikke riktig på grunn av at prefikset vårt (url-skjemaet) har tall, og det regulære uttrykket sjekker kun tegnsettet som består av :alpha: prikker og bindestreker. Etter å ha konsultert rfc3986-standarden for enhetlig ressursidentifikator Det ble klart at denne gangen ikke Microsoft bryter noe (selv om jeg hadde en slik versjon). Bare tegnklassen :alpha: inneholder bare bokstaver i det latinske alfabetet. Jeg endrer raskt den vanlige sjekken til alfanumerisk. Ferdig, du er fantastisk, alt starter endelig, kontroll etter alle sjekker er gitt til skriptapplikasjonen vår, lenken vår vises på konsollen, alt er som det skal. Etter dette begynner jeg å mistenke at alle problemene med exo-open også skyldes valideringen av lenkeformatet på grunn av tallene i ordningen. For å teste hypotesen endrer jeg mime-typeregistreringen av applikasjonen til bare et skjema Lync og voila - alt fungerer uten å overstyre open_xfce-funksjonen. Men dette vil ikke hjelpe oss på noen måte, fordi nettsiden for å delta på konferansen lager en kobling med lync15.
Så den første delen av reisen er fullført. Vi vet hvordan vi avskjærer et koblingsanrop, og så må det på en eller annen måte behandles og sendes i Pidgin. For å forstå hvordan det fungerer internt når jeg legger inn data via en lenke i «bli med på en konferanse»-menyen, klonet jeg Git-depotet til Sipe-prosjektet og gjorde meg klar til å dykke inn i koden igjen. Men så ble jeg heldigvis tiltrukket av manusene i katalogen contrib/dbus/:
- sipe-join-conference-with-uri.pl
- sipe-join-conference-with-arrangør-and-id.pl
- sipe-call-telefonnummer.pl
- SipeHelper.pm
Det viser seg at Sipe-pluginen er tilgjengelig for interaksjon via dbus (skrivebordsbuss) og inne i skriptene er det eksempler på å bli med på en konferanse via en lenke, enten gjennom arrangørens navn og conf-id, eller du kan starte en samtale via sip . Det var akkurat dette vi manglet.
Trinn 2. Implementering av en autojoin-behandler
Siden det er ferdige eksempler i Pearl, bestemte jeg meg for å bare bruke sipe-join-conference-with-uri.pl og modifiser den litt for å passe deg selv. Jeg kan skrive i Pearl, så det forårsaket ingen spesielle vanskeligheter.
Etter å ha testet skriptet separat, skrev jeg kallet inn i filen lync.desktop. Og det var en seier! Når du går inn på deltakelsessiden for konferansen og lar xdg-open kjøre, åpnes konferansevinduet fra Pidgin automatisk. Som jeg gledet meg.
Oppmuntret av suksessen bestemte jeg meg for å gjøre det samme for hovednettleseren min, Mozilla Firefox. Når du logger inn gjennom reven åpnes en side for autorisasjon og helt nederst er det en knapp bli med ved hjelp av kontorkommunikator. Det var hun som fanget oppmerksomheten min. Når du klikker på den i nettleseren, går den til adressen:
conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}%3Frequired-media=audio
som han vennlig forteller meg at han ikke vet hvordan han skal åpne den, og at jeg kanskje ikke har et tilknyttet program for en slik protokoll. Vel, vi har allerede vært gjennom dette.
Jeg registrerer raskt manussøknaden min også for uri-ordningen conf og... ingenting skjer. Nettleseren fortsetter å klage over at det ikke finnes noen applikasjoner som håndterer koblingene mine. I dette tilfellet fungerer det perfekt å kalle xdg-open fra konsollen med parametere.
"Angi tilpasset protokollbehandler i firefox" - Jeg gikk på nettet med dette spørsmålet. Etter å ha gått gjennom flere diskusjoner om stackoverflow (og hvor ville vi vært uten det), ser det ut til at svaret ble funnet. Du må opprette en spesiell parameter i about: config (selvfølgelig erstatte foo med conf):
network.protocol-handler.expose.foo = false
Vi oppretter den, åpner lenken og... ingen slik hell. Nettleseren, som om ingenting hadde skjedd, sier at den ikke kjenner applikasjonen vår.
Jeg leser den offisielle dokumentasjonen om registrering av en protokoll fra Mozilla, det er et alternativ for å registrere assosiasjoner i selve gnome-skrivebordet (erstatter foo med conf, selvfølgelig):
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
Jeg registrerer meg, åpner nettleseren... og igjen skjegget.
Her fanger jeg en linje fra dokumentasjonen:
Neste gang du klikker på en lenke av protokolltype foo vil du bli spurt om hvilket program du skal åpne det med.
— Semyon Semenych
- Ahh
Vi klikker ikke på lenken, men nettsiden endrer ganske enkelt window.location via javascript. Jeg skriver en enkel html-fil med en lenke til conf-protokollen, åpner den i nettleseren, klikker på lenken - Yos! Et vindu åpnes som spør i hvilken applikasjon vi trenger for å åpne lenken vår, og der har vi allerede Lync-applikasjonen vår på listen - vi registrerte den ærlig på alle mulige måter. Der i vinduet er det en avmerkingsboks "husk valget og åpne alltid lenker i applikasjonen vår", merk den, klikk ok. Og dette er den andre seieren - konferansevinduet åpnes. Samtidig fungerer åpning av konferanser ikke bare når du klikker på en lenke, men også når du flytter fra påmeldingssiden vi trenger til konferansen.
Så sjekket jeg og slettet parametere network.protocol-handler.expose.conf ikke på noen måte påvirket driften av protokollen i Fox. Linkene fortsatte å fungere.
Konklusjon
Jeg har lastet opp alt arbeidet mitt til GitHub-depotet; lenker til alle ressurser vil være på slutten av artikkelen.
Jeg vil være interessert i å få tilbakemeldinger fra de som ønsker å bruke arbeidet mitt. Jeg bør umiddelbart merke meg at jeg gjorde all utviklingen bare for Linux Mint-systemet mitt, så noen andre distribusjoner eller skrivebord fungerer kanskje ikke i den versjonen. Eller rettere sagt, jeg er til og med nesten sikker på dette, fordi jeg lappet bare 1 funksjon i xdg-open som kun er relatert til min DE. Hvis du vil legge til støtte for andre systemer eller skrivebord, skriv meg pull-forespørsler på Github.
Hele prosjektet tok 1 kveld å fullføre.
referanser:
Kilde: www.habr.com