Hej Habr!
For mig er denne sætning beslægtet med hello world, siden jeg endelig nåede til min første udgivelse. Jeg udskyde dette vidunderlige øjeblik i lang tid, da der ikke var noget at skrive om, og jeg ville heller ikke suge på noget, der allerede var blevet suget til en masse gange. Generelt ønskede jeg til min første udgivelse noget originalt, nyttigt for andre og indeholdende en form for udfordring og problemløsning. Og nu kan jeg dele dette. Lad os nu tale om alt i rækkefølge.
Indrejse
Det hele startede, da jeg for noget tid siden downloadede Linux Mint på min arbejdscomputer. Mange ved nok, at Pidgin med Sipe-plugin'et er en helt passende erstatning for Microsoft Lync (nu kaldet Skype for business) til Linux-systemer. På grund af de særlige forhold i mit arbejde, er jeg ofte nødt til at deltage i SIP-konferencer, og da jeg var Windows-medarbejder, var det elementært at deltage i konferencer: vi modtager en invitation på mail, klik på login-linket, og vi er klar til at gå .
Når du skiftede til den mørke side af Linux, blev alt noget mere kompliceret: selvfølgelig kan du også logge på konferencer i Pidgin, men for at gøre dette skal du vælge muligheden for at deltage i konference i menuen i egenskaberne for din SIP-konto og indsæt et link til konferencen i det vindue, der åbnes, eller indtast navnet på arrangøren og konfid. Og efter nogen tid begyndte jeg at tænke: "er det muligt på en eller anden måde at forenkle dette?" Ja, kan du sige, hvorfor fanden har du brug for det? Jeg vil hellere sidde på Windows og ikke blæse mig.
Trin 1: Forskning
"Hvis du får en form for indfald i dit hoved, kan du ikke slå det ud med en indsats" - dette er, hvad Nekrasov sagde i sit værk "Who Lives Well in Rus'."
Så da tanken først kom ind i mit hoved, opstod efter nogen tid den første idé til implementering. Alt virkede simpelt - du skal opsnappe adgang til links — installer en lokal webapplikationsproces på din bil på 127.0.0.1 og i /etc/hosts tilføj en statisk indgang for firmaets domæne, hvorigennem du går ind i konferencen, og peger på localhost. Dernæst skal denne webserver behandle linket, der kom til den og på en eller anden måde overføre det inde i Pidgin (jeg siger med det samme, at jeg på dette tidspunkt stadig ikke havde nogen idé om, hvordan jeg overhovedet skulle give den til den). Løsningen lugter selvfølgelig af krykker, men vi er programmører, krykker skræmmer os ikke (shit).
Så åbnede jeg ved et tilfælde på en eller anden måde invitationslinket i Google Chrome (og normalt bruger jeg altid Mozilla Firefox). Og til min overraskelse så websiden helt anderledes ud - der var ingen formular til indtastning af brugerdata og umiddelbart efter indtastning på siden kom der en anmodning om at åbne noget igennem xdg-open. For sjov klikker jeg på "ja", og der kommer en fejlmeddelelse - linket lync15:confjoin?url=https://meet.company.com/user/confid kan ikke åbnes. Hmm. Hvilken slags xdg-open er dette, og hvad skal der til, for at sådanne links kan åbne? En post mortem-læsning af dokumentationen afslørede, at det er en GUI-handler, der hjælper med at køre tilknyttede applikationer enten med protokoller til uri-skemaet eller med specifikke filtyper. Tilknytninger konfigureres via mime-type mapping. Så vi ser, at vi kører en søgning efter en matchet applikation til en uri-ordning ved navn lync15 og linket sendes til xdg-open, som så i teorien skulle videregive det til en applikation, der er ansvarlig for denne type link. Hvilket vi selvfølgelig ikke har i vores system. Hvis ikke, hvad gør de så i open source-verdenen? Det er rigtigt, vi skriver det selv.
Yderligere fordybelse i Linux-verdenen og især i at studere, hvordan den grafiske shell (skrivebordsmiljø, DE) fungerer, i øvrigt har jeg Xfce i Linux Mint, viste, at applikationer og den mime-type, der er forbundet med den, normalt skrives direkte i genvejsfiler med filtypenavnet .desktop. Nå, hvorfor ikke, jeg opretter en simpel applikationsgenvej, som blot skal starte et bash-script og udlæse argumentet, der er sendt til det til konsollen, jeg giver kun selve genvejsfilen:
[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 det samme link, som kommer fra browseren og... ærgerligt. Igen står der, at den ikke kan behandle linket.
Som det viser sig, opdaterede jeg ikke mappen med tilknyttede mime-typer med min applikation. Dette gøres med en simpel kommando:
xdg-mime default lync.desktop x-scheme-handler/lync15
som blot redigerer filen ~/.config/mimeapps.list.
Forsøg nummer 2 med xdg-open-kaldet - og igen fiasko. Intet, vanskeligheder skræmmer os ikke, men nærer kun vores interesse. Og bevæbnet med al kraften fra bash (dvs. sporing) dykker vi med hovedet først ind i fejlretning. Det er vigtigt at bemærke her, at xdg-open kun er et shell-script.
bash -x xdg-open $url
Ved at analysere outputtet efter sporing bliver det lidt tydeligt, at kontrollen så overføres til exo-åben. Og dette er allerede en binær fil, og det er sværere at forstå, hvorfor den returnerer en mislykket returkode, når den sender et link til den i et argument.
Efter at have kigget gennem det interne af xdg-open fandt jeg ud af, at det analyserer forskellige miljøparametre og sender kontrollen videre enten til nogle værktøjer til at åbne fillinks, der er specifikke for en bestemt DE, eller den har en reservefunktion åben_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 hurtigt indlejre her et lille hack med analyse af det beståede argument, og om vores specifikke understreng er placeret der lync15:, så overfører vi straks kontrollen til funktionen åben_generisk.
Forsøg nummer 3 og tror du det virkede? Ja, nu, selvfølgelig. Men fejlmeddelelsen er allerede ændret, dette er allerede fremskridt - nu fortalte han mig, at filen ikke blev fundet, og i form af en fil skrev han mig det samme link, der blev sendt som et argument.
Denne gang viste det sig at være en funktion is_file_url_or_path, som analyserer fillinket, der sendes til input: file:// eller stien til filen eller noget andet. Og kontrollen virkede ikke korrekt på grund af, at vores præfiks (url-skema) har tal, og det regulære udtryk kontrollerer kun tegnsættet bestående af :alpha: prikker og bindestreger. Efter at have konsulteret rfc3986-standarden for ensartet ressourceidentifikator Det blev klart, at Microsoft denne gang ikke krænker noget (selvom jeg havde sådan en version). Bare tegnklassen :alpha: indeholder kun bogstaver i det latinske alfabet. Jeg ændrer hurtigt den almindelige kontrol til alfanumerisk. Færdig, du er fantastisk, alt starter endelig, kontrol efter alle kontroller er givet til vores script-applikation, vores link vises på konsollen, alt er som det skal være. Herefter begynder jeg at få mistanke om, at alle problemerne med exo-open også skyldes valideringen af linkformatet på grund af tallene i ordningen. For at teste hypotesen ændrer jeg applikationens mime-type registrering til kun et skema Los og voila - alt fungerer uden at tilsidesætte open_xfce-funktionen. Men dette vil ikke hjælpe os på nogen måde, fordi websiden for at deltage i konferencen skaber et link til lync15.
Så den første del af rejsen er overstået. Vi ved, hvordan man opsnapper et linkkald, og så skal det på en eller anden måde behandles og sendes inde i Pidgin. For at forstå, hvordan det fungerer internt, når der indtastes data via et link i menuen "deltag i en konference", klonede jeg Sipe-projektets Git-lager og gjorde mig klar til at dykke ned i koden igen. Men så blev jeg heldigvis tiltrukket af manuskripterne i kataloget bidrag/dbus/:
- sipe-join-conference-with-uri.pl
- sipe-join-konference-med-arrangør-og-id.pl
- sipe-call-phone-number.pl
- SipeHelper.pm
Det viser sig, at Sipe plugin'et er tilgængeligt for interaktion via dbus (desktop bus) og inde i scripts er der eksempler på at deltage i en konference via et link, enten gennem arrangørens navn og conf-id, eller du kan starte et opkald via sip . Det var præcis, hvad vi manglede.
Trin 2. Implementering af en autojoin-handler
Da der er færdige eksempler i Pearl, besluttede jeg mig for bare at bruge sipe-join-conference-with-uri.pl og modificere det lidt, så det passer til dig selv. Jeg kan skrive i Pearl, så det voldte ikke særlige vanskeligheder.
Efter at have testet scriptet separat, skrev jeg dets opkald ind i filen lync.desktop. Og det var en sejr! Når du går ind på konferencedeltagelsessiden og tillader xdg-open at køre, åbnes konferencens popup-vindue fra Pidgin automatisk. Hvor jeg glædede mig.
Opmuntret af succesen besluttede jeg at gøre det samme for min hovedbrowser, Mozilla Firefox. Når du logger ind gennem ræven, åbner en side for autorisation og helt nederst er der en knap deltage ved hjælp af Office communicator. Det var hende, der fangede min opmærksomhed. Når du klikker på den i browseren, går den til adressen:
conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}%3Frequired-media=audio
hvortil han venligt fortæller mig, at han ikke ved, hvordan man åbner den, og måske har jeg ikke en tilknyttet applikation til sådan en protokol. Nå, vi har allerede været igennem det her.
Jeg registrerer hurtigt min scriptansøgning også til uri-ordningen conf og... der sker ikke noget. Browseren bliver ved med at klage over, at der ikke er nogen applikation, der håndterer mine links. I dette tilfælde fungerer det perfekt at kalde xdg-open fra konsollen med parametre.
"Set brugerdefineret protokolhandler i firefox" - Jeg gik online med dette spørgsmål. Efter at have gennemgået flere diskussioner om stackoverflow (og hvor ville vi være uden det), ser det ud til, at svaret blev fundet. Du skal oprette en speciel parameter i about: config (selvfølgelig erstatter foo med conf):
network.protocol-handler.expose.foo = false
Vi opretter det, åbner linket og... ikke sådan noget held. Browseren siger, som om intet var hændt, at den ikke kender vores applikation.
Jeg læser den officielle dokumentation om registrering af en protokol fra Mozilla, der er en mulighed for at registrere associationer i selve gnome-skrivebordet (der erstatter selvfølgelig foo med conf):
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 mig, åbner browseren... og igen skægget.
Her falder en linje fra dokumentationen i øjnene:
Næste gang du klikker på et link af protokol-type foo, vil du blive spurgt, hvilket program du skal åbne det med.
— Semyon Semenych
- Ahh
Vi klikker ikke på linket, men websiden ændrer blot window.location via javascript. Jeg skriver en simpel html-fil med et link til conf-protokollen, åbner den i browseren, klik på linket - Yos! Der åbnes et vindue, der spørger i hvilken applikation vi skal åbne vores link, og der har vi allerede vores Lync-applikation på listen - vi har ærligt registreret det på alle mulige måder. Der i vinduet er der et afkrydsningsfelt "husk valget og åbn altid links i vores applikation", marker det, klik ok. Og dette er den anden sejr - konferencevinduet åbner. Samtidig fungerer åbning af konferencer ikke kun, når du klikker på et link, men også når du flytter fra den deltagelsesside, vi skal bruge, til konferencen.
Så tjekkede jeg og slettede parametre network.protocol-handler.expose.conf på ingen måde påvirkede driften af protokollen i Fox. Linkene fortsatte med at fungere.
Konklusion
Jeg har uploadet alt mit arbejde til GitHub-lageret; links til alle ressourcer vil være i slutningen af artiklen.
Jeg vil være interesseret i at modtage feedback fra dem, der ønsker at bruge mit arbejde. Jeg skal straks bemærke, at jeg kun lavede hele udviklingen til mit Linux Mint-system, så nogle andre distributioner eller desktops fungerer muligvis ikke i den version. Eller rettere sagt, jeg er endda næsten sikker på dette, fordi jeg kun har patchet 1 funktion i xdg-open, der kun vedrører min DE. Hvis du vil tilføje support til andre systemer eller desktops, skriv mig pull-anmodninger på Github.
Hele projektet tog 1 aften at gennemføre.
referencer:
Kilde: www.habr.com