Hej Habr!
För mig är den här frasen besläktad med hello world, eftersom jag äntligen kom till min första publikation. Jag sköt upp det här underbara ögonblicket länge, eftersom det inte fanns något att skriva om, och jag ville inte heller suga på något som redan hade sugits på ett gäng gånger. I allmänhet, för min första publikation ville jag ha något originellt, användbart för andra och innehållande någon form av utmaning och problemlösning. Och nu kan jag dela detta. Låt oss nu prata om allt i ordning.
Entry
Allt började när jag för en tid sedan laddade ner Linux Mint på min arbetsdator. Många vet säkert att Pidgin med Sipe-plugin är en helt passande ersättning för Microsoft Lync (numera kallat Skype for business) för Linux-system. På grund av detaljerna i mitt arbete måste jag ofta delta i SIP-konferenser, och när jag var en Windows-arbetare var det grundläggande att delta i konferenser: vi får en inbjudan per post, klicka på inloggningslänken och vi är redo att börja .
När man bytte till den mörka sidan av Linux blev allt något mer komplicerat: naturligtvis kan du logga in på konferenser i Pidgin, men för att göra detta måste du välja alternativet gå med i konferens i menyn i egenskaperna för ditt SIP-konto och i fönstret som öppnas, infoga en länk till konferensen eller ange namnet på arrangören och konf id. Och efter en tid började jag tänka: "är det möjligt att på något sätt förenkla detta?" Ja, du kanske kan säga, varför i helvete behöver du det här? Jag sitter hellre på Windows och inte får mig att bli förkyld.
Steg 1: Forskning
"Om du får ett infall i huvudet kan du inte slå ut det med en påle", sa Nekrasov i sitt verk "Who Lives Well in Rus'."
Så, när tanken väl kom in i mitt huvud, uppstod efter en tid den första idén för implementering. Allt verkade enkelt - du måste fånga åtkomst till länkar — installera en lokal webbapplikationsprocess på din bil på 127.0.0.1 och i /etc/hosts lägg till en statisk post för företagsdomänen genom vilken du går in i konferensen och pekar på localhost. Därefter måste den här webbservern bearbeta länken som kom till den och på något sätt överföra den inuti Pidgin (jag ska genast säga att jag i det här skedet fortfarande inte hade någon aning om hur jag skulle ge den till den alls). Lösningen luktar naturligtvis kryckor, men vi är programmerare, kryckor skrämmer oss inte (shit).
Sedan, av en slump, öppnade jag på något sätt inbjudningslänken i Google Chrome (och vanligtvis använder jag alltid Mozilla Firefox). Och till min förvåning såg webbsidan helt annorlunda ut - det fanns inget formulär för att ange användardata och direkt efter att ha kommit in på sidan kom en begäran om att öppna något genom xdg-öppen. Bara för skojs skull klickar jag på "ja" och ett felmeddelande visas - länken lync15:confjoin?url=https://meet.company.com/user/confid kan inte öppnas. Hmm. Vilken typ av xdg-open är detta och vad behöver den för att sådana länkar ska öppnas? En obduktionsläsning av dokumentationen avslöjade att det är en GUI-hanterare som hjälper till att köra associerade applikationer antingen med protokoll för uri-schemat eller med specifika filtyper. Associationer konfigureras via mappning av mimetyp. Så vi ser att vi kör en sökning efter en matchad applikation för ett uri-schema med namnet lync15 och länken skickas till xdg-open, som sedan, i teorin, borde skicka den till någon applikation som är ansvarig för denna typ av länk. Vilket vi naturligtvis inte har i vårt system. Om inte, vad gör de då i världen med öppen källkod? Just det, vi skriver det själva.
Ytterligare fördjupning i Linux-världen och speciellt i att studera hur det grafiska skalet (skrivbordsmiljö, DE) fungerar, förresten, jag har Xfce i Linux Mint, visade att applikationer och den mime-typ som är förknippad med det vanligtvis skrivs direkt i genvägsfiler med filtillägget .desktop. Tja, varför inte, jag skapar en enkel applikationsgenväg, som helt enkelt ska starta ett bash-skript och mata ut argumentet som skickas till det till konsolen, jag tillhandahåller bara genvägsfilen själv:
[Desktop Entry]
Name=Lync
Exec=/usr/local/bin/lync.sh %u
Type=Application
Terminal=false
Categories=Network;InstantMessaging;
MimeType=x-scheme-handler/lync15;
Jag startar xdg-open från konsolen, skickar samma länk som kommer från webbläsaren och... tråkigt. Återigen står det att den inte kan behandla länken.
Som det visar sig uppdaterade jag inte katalogen med tillhörande mime-typer med min applikation. Detta görs med ett enkelt kommando:
xdg-mime default lync.desktop x-scheme-handler/lync15
som helt enkelt redigerar filen ~/.config/mimeapps.list.
Försök nummer 2 med xdg-open-anropet - och återigen misslyckande. Ingenting, svårigheter skrämmer oss inte, utan väcker bara vårt intresse. Och beväpnade med all kraft av bash (dvs spårning), dyker vi med huvudet först in i felsökning. Det är viktigt att notera här att xdg-open bara är ett skalskript.
bash -x xdg-open $url
Genom att analysera utsignalen efter spårning blir det lite tydligt att kontrollen sedan överförs till exo-öppet. Och det här är redan en binär fil och det är svårare att förstå varför den returnerar en misslyckad returkod när den skickar en länk till den i ett argument.
Efter att ha tittat igenom det interna innehållet i xdg-open fick jag reda på att det analyserar olika miljöparametrar och skickar kontrollen vidare antingen till några verktyg för att öppna fillänkar specifika för en viss DE, eller så har den en reservfunktion open_generic
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
}
Jag kommer snabbt att bädda in här ett litet hack med analys av det godkända argumentet och om vår specifika delsträng finns där lync15:, då överför vi omedelbart kontrollen till funktionen open_generic.
Försök nummer 3 och tror du att det fungerade? Ja, nu såklart. Men felmeddelandet har redan ändrats, detta är redan framsteg - nu berättade han för mig att filen inte hittades och i form av en fil skrev han samma länk till mig som ett argument.
Den här gången visade det sig vara en funktion is_file_url_or_path, som analyserar fillänken som skickas till ingången: file:// eller sökvägen till filen eller något annat. Och kontrollen fungerade inte korrekt på grund av att vårt prefix (url-schema) har siffror, och det reguljära uttrycket kontrollerar bara teckenuppsättningen som består av :alpha: punkter och streck. Efter att ha konsulterat standarden rfc3986 för enhetlig resursidentifierare Det blev tydligt att Microsoft denna gång inte bryter mot något (även om jag hade en sådan version). Bara teckenklassen :alpha: innehåller endast bokstäver i det latinska alfabetet. Jag ändrar snabbt den vanliga kontrollen till alfanumerisk. Klar, du är fantastisk, allt börjar äntligen, kontroll efter alla kontroller ges till vår skriptapplikation, vår länk visas på konsolen, allt är som det ska. Efter detta börjar jag misstänka att alla problem med exo-open också beror på valideringen av länkformatet på grund av siffrorna i schemat. För att testa hypotesen ändrar jag applikationens mimetypsregistrering till bara ett schema lync och voila - allt fungerar utan att åsidosätta open_xfce-funktionen. Men detta kommer inte att hjälpa oss på något sätt, eftersom webbsidan för att delta i konferensen skapar en länk till lync15.
Så, den första delen av resan är avklarad. Vi vet hur man avlyssnar ett länksamtal och sedan måste det på något sätt bearbetas och skickas in i Pidgin. För att förstå hur det fungerar internt vid inmatning av data via en länk i menyn "join a conference", klonade jag Git-förrådet i Sipe-projektet och gjorde mig redo att dyka in i koden igen. Men sedan, lyckligtvis, lockades jag av manusen i katalogen contrib/dbus/:
- sipe-join-conference-with-uri.pl
- sipe-join-conference-with-organizer-and-id.pl
- sipe-call-phone-number.pl
- SipeHelper.pm
Det visar sig att Sipe-plugin är tillgänglig för interaktion via dbus (skrivbordsbuss) och inne i skripten finns exempel på att gå med i en konferens via en länk, antingen genom arrangörens namn och conf-id, eller så kan man initiera ett samtal via sip . Det är precis vad vi saknade.
Steg 2. Implementera en autojoin-hanterare
Eftersom det finns färdiga exempel i Pearl bestämde jag mig för att bara använda sipe-join-conference-with-uri.pl och modifiera det lite för att passa dig själv. Jag kan skriva i Pearl, så det orsakade inga särskilda svårigheter.
Efter att ha testat skriptet separat skrev jag in dess anrop i filen lync.desktop. Och det var en seger! När du går in på konferensanslutningssidan och låter xdg-open köras, öppnas konferensens popup-fönster från Pidgin automatiskt. Vad jag gladde mig.
Uppmuntrad av framgången bestämde jag mig för att göra samma sak för min huvudwebbläsare, Mozilla Firefox. När du loggar in genom räven öppnas en sida för auktorisering och allra längst ner finns en knapp gå med med hjälp av Office communicator. Det var hon som fångade min uppmärksamhet. När du klickar på den i webbläsaren går den till adressen:
conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}%3Frequired-media=audio
som han vänligt säger till mig att han inte vet hur man öppnar det och att jag kanske inte har en tillhörande applikation för ett sådant protokoll. Tja, vi har redan varit med om det här.
Jag registrerar snabbt min manusansökan även för uri-schemat conf och... ingenting händer. Webbläsaren klagar hela tiden på att det inte finns någon applikation som hanterar mina länkar. I det här fallet fungerar det perfekt att anropa xdg-open från konsolen med parametrar.
"Ställ in anpassad protokollhanterare i firefox" - Jag gick online med den här frågan. Efter att ha gått igenom flera diskussioner om stackoverflow (och var skulle vi vara utan det), verkar det som att svaret har hittats. Du måste skapa en speciell parameter i about: config (naturligtvis ersätter foo med conf):
network.protocol-handler.expose.foo = false
Vi skapar den, öppnar länken och... ingen sådan tur. Webbläsaren, som om ingenting hade hänt, säger att den inte känner till vår applikation.
Jag läser den officiella dokumentationen om att registrera ett protokoll från Mozilla, det finns ett alternativ att registrera associationer i själva gnome-skrivbordet (ersätter foo med conf, naturligtvis):
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
Jag registrerar mig, öppnar webbläsaren... och igen skägget.
Här får jag ögonen på mig en rad från dokumentationen:
Nästa gång du klickar på en länk av protokolltyp foo kommer du att bli tillfrågad vilket program du ska öppna det med.
— Semyon Semenych
- Ahh
Vi klickar inte på länken, utan webbsidan ändrar helt enkelt window.location via javascript. Jag skriver en enkel html-fil med en länk till conf-protokollet, öppnar den i webbläsaren, klickar på länken - Yos! Ett fönster öppnas som frågar i vilken applikation vi behöver för att öppna vår länk, och där har vi redan vår Lync-applikation i listan - vi registrerade den ärligt talat på alla möjliga sätt. Där i fönstret finns en kryssruta "kom ihåg valet och öppna alltid länkar i vår applikation", markera den, klicka på ok. Och det här är den andra segern - konferensfönstret öppnas. Samtidigt fungerar öppning av konferenser inte bara när du klickar på en länk, utan även när du flyttar från den anslutningssida vi behöver till konferensen.
Sedan kollade jag och tog bort parametrar network.protocol-handler.expose.conf inte på något sätt påverkade driften av protokollet i Fox. Länkarna fortsatte att fungera.
Slutsats
Jag har laddat upp allt mitt arbete till GitHub-förvaret; länkar till alla resurser finns i slutet av artikeln.
Jag kommer att vara intresserad av att få feedback från de som vill använda mitt arbete. Jag bör omedelbart notera att jag gjorde all utveckling endast för mitt Linux Mint-system, så vissa andra distributioner eller stationära datorer kanske inte fungerar i den versionen. Eller rättare sagt, jag är till och med nästan säker på detta, eftersom jag bara lappade en funktion i xdg-open som bara relaterar till min DE. Om du vill lägga till stöd för andra system eller stationära datorer, skriv mig pull-förfrågningar på Github.
Hela projektet tog 1 kväll att slutföra.
Länkar:
Källa: will.com