嘿哈布爾！
對我來說，這句話類似於 hello world，因為我終於發表了第一篇文章。 我把這個美好的時刻推遲了很長一段時間，因為沒有什麼可寫的，而且我也不想吸吮已經吸了很多次的東西。 總的來說，對於我的第一篇出版物，我想要一些原創的、對其他人有用的東西，並包含某種挑戰和解決問題的內容。 現在我可以分享這個了。 現在讓我們按順序談談一切。
條目
這一切都是從不久前我在工作電腦上下載 Linux Mint 開始的。 許多人可能知道帶有 Sipe 插件的 Pidgin 是 Linux 系統上 Microsoft Lync（現在稱為 Skype for Business）的完全合適的替代品。 由於工作的特殊性，我經常要參加SIP會議，當我還是Windows工作人員時，進入會議是初級的：我們收到郵件邀請，點擊登入鏈接，然後就可以出發了。
當切換到 Linux 的黑暗面時，一切都變得更加複雜：當然，您也可以在 Pidgin 中登入會議，但要做到這一點，您需要在 SIP 帳戶屬性的選單中選擇加入會議選項，然後在打開的視窗中，插入會議連結或輸入組織者的名稱和會議ID。 一段時間後，我開始思考：“是否有可能以某種方式簡化這個過程？” 是的，你可能會說，你到底為什麼需要這個？我寧願坐在 Windows 上也不會讓我大吃一驚。
第一步：研究
涅克拉索夫在他的著作《誰在羅斯生活得很好》中說道：“如果你腦子裡突發奇想，你無法用木樁把它打倒。”
所以，一旦這個想法進入我的腦海，過了一段時間，第一個實施的想法就出現了。 一切看起來都很簡單 - 您需要攔截對連結的訪問 — 在您的汽車上安裝本機 Web 應用程式進程（位址為 127.0.0.1），並在 /etc/hosts 中為您進入會議的公司網域新增靜態項目，指向 localhost。 接下來，這個網頁伺服器必須處理到達它的鏈接，並以某種方式將其傳輸到 Pidgin 內部（我會立即說，在這個階段我仍然不知道如何將其提供給它）。 當然，解決方案聞起來像拐杖，但我們是程式設計師，拐杖不會嚇到我們（狗屎）。
然後，一個偶然的機會，我以某種方式在 Google Chrome 中開啟了邀請連結（通常我總是使用 Mozilla Firefox）。 令我驚訝的是，該網頁看起來完全不同 - 沒有用於輸入用戶資料的表單，進入頁面後立即有一個通過以下方式打開某些內容的請求 XDG開。 只是為了好玩，我點擊“是”，然後出現一條錯誤訊息 - 連結 lync15:confjoin?url=https://meet.company.com/user/confid 無法打開。 唔。 這是什麼類型的 xdg-open？它需要什麼才能打開此類連結？ 文件的事後分析表明，它是一個 GUI 處理程序，可協助運行具有 uri 方案協議或特定文件類型的關聯應用程式。 關聯是透過 mime 類型映射來配置的。 因此，我們看到我們正在搜尋名為 uri 方案的匹配應用程式 lync15 並且連結被傳遞給 xdg-open，理論上，xdg-open 應該將其傳遞給負責此類連結的某個應用程式。 當然，我們的系統中沒有。 如果沒有，那麼他們在開源世界裡做什麼？ 沒錯，我們自己寫。
進一步沉浸在 Linux 世界中，特別是研究圖形 shell（桌面環境，DE）如何工作，順便說一句，我在 Linux Mint 中有 Xfce，表明應用程式和與之相關的 mime 類型通常直接編寫在擴展名為.desktop 的捷徑檔案。 好吧，為什麼不呢，我創建一個簡單的應用程式快捷方式，它應該簡單地啟動一個 bash 腳本並將傳遞給它的參數輸出到控制台，我只提供快捷方式文件本身：
[Desktop Entry]
Name=Lync
Exec=/usr/local/bin/lync.sh %u
Type=Application
Terminal=false
Categories=Network;InstantMessaging;
MimeType=x-scheme-handler/lync15;
我從控制台啟動 xdg-open，傳遞來自瀏覽器的相同鏈接，然後…真糟糕。 它再次表示無法處理該連結。
事實證明，我沒有使用我的應用程式更新關聯 mime 類型的目錄。 這是透過一個簡單的命令完成的：
xdg-mime default lync.desktop x-scheme-handler/lync15
它只是編輯文件 〜/.config/mimeapps.list.
嘗試使用 xdg-open 呼叫進行 2 次嘗試，但再次失敗。 沒什麼，困難不會嚇到我們，只會激發我們的興趣。 並配備了 bash 的所有功能（即跟踪），我們一頭扎進調試。 這裡要注意的是，xdg-open 只是一個 shell 腳本。
bash -x xdg-open $url
追蹤後分析輸出，可以清楚看出控制權隨後轉移到 外開放。 而且這已經是一個二進位文件，更難以理解為什麼在參數中傳遞指向它的連結時它會傳回不成功的回傳程式碼。
在查看了 xdg-open 的內部結構後，我發現它會分析各種環境參數，並將控制進一步傳遞給一些用於開啟特定於特定 DE 的檔案連結的工具，或者它具有後備功能 開放通用
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
}
我將快速在這裡嵌入一個小技巧，分析傳遞的參數以及我們的特定子字串是否位於那裡 lync15：，然後我們立即將控制權轉移給該函數 開放通用.
試試第三個，你認為它有效嗎？ 是的，現在，當然。 但是錯誤訊息已經改變了，這已經是進步了 - 現在他告訴我找不到該文件，並且他以文件的形式給我寫了作為參數傳遞的相同連結。
這次竟然是個函數 is_file_url_or_path，它分析傳遞給輸入的文件連結： file:// 或文件的路徑或其他內容。 由於我們的前綴（url 方案）包含數字，且正規表示式僅檢查由 :alpha: 點和破折號組成的字元集，因此檢查無法正常運作。 查閱了rfc3986標準後 統一資源標識符 很明顯，這次微軟沒有違反任何規定（儘管我有這樣的版本）。 僅字元類別 :alpha: 只包含拉丁字母表中的字母。 我很快就將常規檢查更改為字母數字。 完成了，你太棒了，一切終於開始了，所有檢查後的控制權都交給了我們的腳本應用程序，我們的鏈接顯示在控制台上，一切都應該如此。 在此之後，我開始懷疑 exo-open 的所有問題也是由於方案中的數字對連結格式的驗證所造成的。 為了測試假設，我將應用程式的 mime 類型註冊更改為一個方案 林肯 瞧 - 一切正常，無需覆蓋 open_xfce 函數。 但這對我們沒有任何幫助，因為進入會議的網頁創建了與lync15的連結。
至此，旅程的第一部分已經完成。 我們知道如何攔截連結調用，然後需要以某種方式處理並在 Pidgin 內傳遞。 為了了解透過「加入會議」選單中的連結輸入資料時它的內部工作原理，我克隆了 Sipe 專案的 Git 儲存庫，並準備再次深入研究程式碼。 但後來幸運的是，我被目錄中的劇本吸引了 貢獻/dbus/:
- sipe-加入會議-with-uri.pl
- sipe-加入會議與-organizer-and-id.pl
- sipe-call-電話號碼.pl
- SipeHelper.pm
事實證明，Sipe 插件可透過 dbus（桌面總線）進行交互，並且在腳本內有透過連結加入會議的範例，可以透過組織者的名稱和 conf-id，也可以透過 sip 發起呼叫。 這正是我們所缺乏的。
步驟 2. 實現自動連線處理程序
由於 Pearl 中有現成的範例，所以我決定只使用 sipe-加入會議-with-uri.pl 並稍微修改一下以適合自己。 我可以用 Pearl 寫，所以沒有造成任何特別的困難。
單獨測試腳本後，我將其呼叫寫入檔案中 lync.桌面。 這是一場勝利！ 當進入會議加入頁面並允許 xdg-open 運行時，來自 Pidgin 的會議彈出視窗將自動開啟。 我多麼高興啊。
受到成功的鼓舞，我決定對我的主要瀏覽器 Mozilla Firefox 做同樣的事情。 當你透過fox登入時，會開啟一個授權頁面，最底部有一個按鈕 使用 Office Communicator 加入。 她是引起我注意的人。 當你在瀏覽器中點擊它時，它會轉到以下地址：
conf:sip:{user};gruu;opaque=app:conf:focus:id:{conf-id}%3Frequired-media=audio
他友善地告訴我，他不知道如何打開它，也許我沒有此類協議的關聯應用程式。 嗯，我們已經經歷過這件事了。
我也快速為 uri 方案註冊我的腳本應用程式 機密 然後……什麼事也沒發生。 瀏覽器不斷抱怨沒有應用程式處理我的連結。 在這種情況下，從控制台使用參數呼叫 xdg-open 效果很好。
「在 Firefox 中設定自訂協定處理程序」 - 我帶著這個問題上網。 在對 stackoverflow 進行了多次討論（以及沒有它我們會怎樣）之後，似乎找到了答案。 您需要在中建立一個特殊參數 about：config中 （當然用conf替換foo）：
network.protocol-handler.expose.foo = false
我們創建了它，打開鏈接，然後......沒有這樣的運氣。 瀏覽器就像什麼都沒發生一樣，說它不知道我們的應用程式。
我正在閱讀有關從 Mozilla 註冊協議的官方文檔，有一個選項可以在 gnome 桌面本身中註冊關聯（當然，用 conf 替換 foo）：
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
我註冊，打開瀏覽器……然後又是鬍子。
文檔中的一行引起了我的注意：
下次您點擊協議類型 foo 的連結時，系統會詢問您使用哪個應用程式開啟它。
— 謝苗·謝梅內奇
- 啊啊
我們不點擊鏈接，但網頁只是透過 javascript 更改 window.location。 我編寫了一個簡單的 html 文件，其中包含 conf 協議的鏈接，在瀏覽器中打開它，單擊該鏈接 - 喲！ 將打開一個窗口，詢問我們需要在哪個應用程式中打開鏈接，列表中已經有我們的 Lync 應用程式 - 我們誠實地以所有可能的方式註冊了它。 視窗中有一個複選框“記住選擇並始終在我們的應用程式中打開連結”，標記它，單擊“確定”。 這是第二次勝利——會議窗口開啟。 同時，開啟會議不僅在點擊連結時有效，而且在從我們需要的加入頁面移動到會議時也有效。
然後我檢查了一下，刪除參數 網路.協議處理程序.expose.conf 不會以任何方式影響該協議在 Fox 中的運作。 這些連結繼續有效。
結論
我已將所有工作上傳到 GitHub 儲存庫；所有資源的連結將位於文章末尾。
我有興趣收到那些想要使用我的作品的人的回饋。 我應該立即註意到，我只為我的 Linux Mint 系統進行了所有開發，因此其他一些發行版或桌面可能無法在該版本中運行。 或者更確切地說，我甚至幾乎可以肯定這一點，因為我只修補了 xdg-open 中僅與我的 DE 相關的 1 個函數。 如果您想添加對其他系統或桌面的支持，請在 Github 上向我寫拉取請求。
整個工程花了1個晚上才完成。
引用：
來源： www.habr.com