Невозможно создать пользовательскую схему URI в Ubuntu

Я создал собственный обработчик схемы URI в RedHat Linux, и он работал как положено. Когда пользователь перенаправляется на пользовательский URI, например: myapp://abcd браузер открывает всплывающее окно запуска приложений, подобное mailto: handler.

Нелегко было сделать подобные шаги в Ubuntu, я попробовал все возможные решения, но ни одно из них не сработало.

Вот что я сделал для RedHat, который работал отлично:

  1. Добавить запись в ~/.local/share/applications/mimeapps.list:

    [Added Associations]
x-scheme-handler/myprotocol=myprotocol-handler.desktop

  2. Добавьте myprotocol-handler.desktop в ~/.local/share/applications/myprotocol-handler.desktop:

    [Desktop Entry]
Version=1.0
Type=Application
Exec=sh -c "$HOME/.my-handler.sh %u"
Icon=
StartupNotify=true
Terminal=false
Categories=Utility;X-XFCE;X-Xfce-Toplevel;
MimeType=x-scheme-handler/myprotocol
Name=My Launcher
Comment=Launch MyProtocol

  3. Создайте ~/.my-handler.sh:

    #!/bin/bash
printf "$code" >> file
xdg-open https://redirect.site.com

Я пробовал описанные выше шаги на Ubuntu, и он не работает, обработчик схемы работает только для xdg-open команда не работает, если я пытаюсь использовать тот же URI в браузере.

Я попробовал следующие места:

~/.config/
~/.local/share/applications/
~/.local/share/applications/packages
sudo update-desktop-database
xdg-mime command

Ни один из подходов не работает, как ожидалось. Может кто-нибудь указать мне правильное направление, моя версия Ubuntu 16.04.4

Источник

0 ответов

Я пробовал вышеуказанные шаги на Ubuntu, и он не работает

Если бы мне пришлось угадывать, я бы сказал, что ваш рабочий стол не может быть исполняемым файлом.

$ if test -x ~/.local/share/applications/myprotocol-handler.desktop; then echo 'executable'; else echo 'not executable'; fi

Вы можете исправить это так:

$ chmod +x ~/.local/share/applications/myprotocol-handler.desktop

Попробуйте сначала.

Кроме того, я вижу сразу несколько других проблем:

  1. Вы регистрируете myapp схема или myprotocol схема?

    Вы упоминаете оба из них, и это несколько сбивает с толку, какие именно URL вы хотите открыть.

    Я предполагаю, что вы хотите использовать myprotocol схема, например myprotocol://abcd,

  2. Запись "Exec" вашего рабочего стола.

    Exec=sh -c "$HOME/.my-handler.sh %u"

    $HOME/ не нужно, если .my-handler.sh в вашем $PATH,

    sh -c не нужен, если ваш скрипт исполняемый, так как в верхней части он содержит строку shebang. Это также добавляет еще один уровень сложности, поскольку все URL-адреса будут расширяться оболочкой до того, как они попадут в сценарий вашего обработчика URL-адресов.

    Строка shebang перечисляет это как скрипт bash (#!/bin/bash), но вы используете sh выполнить вместо этого. Я не вижу какой-либо части сценария, где это будет иметь значение, но по умолчанию sh является dash, другая оболочка из bash,

    $ type -a sh
sh is /bin/sh
$ file /bin/sh
/bin/sh: symbolic link to dash

  3. .my-handler.sh скрипт.

    Вам не нужно делать это скрытым файлом; имя файла как my-handler.sh будет хорошо. Поскольку я сомневаюсь, что ваш домашний каталог находится в $PATH нет никакого преимущества в том, чтобы поместить его в свой домашний каталог, кроме как сделать абсолютный путь немного короче. (Подробнее о $PATH ниже.)

    Ваш шебанг будет работать на Ubuntu:

    $ type -a bash
bash is /bin/bash

    но это хорошая привычка #!/usr/bin/env bash для портативности.

    Вы используете неинициализированную переменную "$code" и добавляете ее в файл с именем file, Какова цель этого? поскольку file это относительный путь, это будет зависеть от рабочего каталога, что, вероятно, не то, что вы хотите. (Для URL-адресов, запущенных из Firefox, это будет зависеть от того, из какого каталога был запущен браузер, который может быть домашним каталогом, но также может быть где-то еще).

    Ваш скрипт никогда не использует "$1" или любые другие аргументы. Это означает, что он по существу отбрасывает переданный URL и открывает https://redirect.site.com вместо.

    Но, возможно, это всего лишь сценарий-заполнитель, и это было сделано намеренно? Если это так, я бы предложил этот тестовый скрипт вместо:

    $ cat .my-handler.sh
#! /usr/bin/env bash
URL="$1"
zenity --info --text "URL: ${URL}\nPWD=${PWD}"

    так что вы можете увидеть переданный URL и каталог, из которого он запущен.

Обработчик схемы работает только для xdg-open команда не работает, если я пытаюсь использовать тот же URI в браузере.

Если xdg-open работает, тогда это просто вопрос настройки браузера. Исходя из ваших комментариев, похоже, что вы используете Firefox, который обрабатывает это в Предпочтения:

Приложения

Выберите, как Firefox обрабатывает файлы, которые вы загружаете из Интернета, или приложения, которые вы используете при просмотре.

Это хранится в handlers.json, как вы упоминаете.

Я попробовал следующие места

Если xdg-open уже работает, это не должно быть проблемой, но одна хитрость в пользовательских обработчиках URL заключается в том, что существует как минимум четыре файла, в которых могут храниться ассоциации, в зависимости от приложения / библиотеки, которую использует приложение:

Мы рассмотрим этот вопрос ниже.

В последнее время я работал над пользовательскими обработчиками URL, поэтому я адаптировал некоторые из них для этой цели. Вот несколько пошаговых инструкций, которые могут вам помочь:

  1. Проверьте, если протокол уже зарегистрирован.

    $ gio mime x-scheme-handler/myprotocol
No default applications for “x-scheme-handler/myprotocol”

    В моем случае протокол еще не зарегистрирован.

  2. Протестируйте скрипт напрямую.

    Вам может понадобиться сделать его исполняемым, например так:

    $ chmod +x ~/.my-handler.sh

    Затем используйте пример URL:

    $ ~/.my-handler.sh 'myprotocol://abcd'

    Исправьте все проблемы здесь, прежде чем продолжить.

  3. Добавьте скрипт в свой $PATH поэтому файл рабочего стола может найти его.

    Этот шаг не является обязательным, но это хорошая привычка. Ввод сценариев в $PATH означает, что вам не нужно будет указывать полный абсолютный путь в файле рабочего стола, поэтому вам не потребуется изменять файл рабочего стола, если путь к вашему сценарию изменится.

    Я использую bin каталог, как это:

    $ mkdir ~/bin/

    и добавить это к ~/.profile (обратите внимание, что вам нужно будет выйти и войти снова, чтобы увидеть изменения):

    PATH="$HOME/bin:$PATH"

    и, наконец, либо скопируйте скрипт, либо ~/bin:

    $ ln -s $PWD/.my-handler.sh ~/bin/

    Если вы сделали это правильно, вы должны что-то похожее на это:

    $ type -a .my-handler.sh
.my-handler.sh is /home/nathaniel/bin/.my-handler.sh

    не это:

    $ type -a .my-handler.sh
bash: type: .my-handler.sh: not found

  4. Установите файл рабочего стола.

    Похоже, вы уже сделали это, но для дальнейшего использования вы можете использовать desktop-file-install команда от desktop-file-utils пакет:

    $ desktop-file-install --dir=$HOME/.local/share/applications/ myprotocol-handler.desktop

    Это самые важные строки в файле рабочего стола:

    Exec=.my-handler.sh %u
MimeType=x-scheme-handler/myprotocol

  5. Убедитесь, что файл рабочего стола является исполняемым.

    Сделайте это так:

    $ chmod +x ~/.local/share/applications/myprotocol-handler.desktop

    Это необходимо в качестве меры безопасности.

  6. Зарегистрируйте файл рабочего стола с помощью x-scheme-handler/myprotocol MimeType.

    $ gio mime x-scheme-handler/myprotocol myprotocol-handler.desktop
Set myprotocol-handler.desktop as the default for x-scheme-handler/myprotocol

    Все, что на самом деле делает, это меняет строки в ~/.config/mimeapps.list под [Default Applications] группа так говорит это:

    x-scheme-handler/myprotocol=myprotocol-handler-desktop

    Некоторые старые приложения используют ~/.local/share/application/mimeapps.list, но это официально не рекомендуется. Однако xdg-mime Команда все равно использует это местоположение:

    $ xdg-mime default myprotocol-handler.desktop x-scheme-handler/myprotocol

    Существует также еще более устаревший файл, который называется defaults.list это все еще используется некоторыми приложениями. Отредактируйте этот файл с помощью текстового редактора:

    $ edit ~/.local/share/applications/defaults.list

    и вручную добавьте эти строки:

    x-scheme-handler/myprotocol=myprotocol-handler.desktop

    под [Default Applications] группа.

  7. Проверьте, было ли оно успешно зарегистрировано.

    $ gio mime x-scheme-handler/myprotocol
Default application for “x-scheme-handler/myprotocol”: myprotocol-handler.desktop
Registered applications:
        myprotocol-handler.desktop
Recommended applications:
        myprotocol-handler.desktop

    Проверьте xdg-mime также.

    $ xdg-mime query default x-scheme-handler/myprotocol
myprotocol-handler.desktop

  8. Проверьте некоторые URL-адреса из командной строки.

    $ gio open 'myprotocol://abcd'

    Теперь протестируйте тот же URL с xdg-open:

    $ xdg-open 'myprotocol://abcd'

  9. Обновите кеш mimeinfo.

    Некоторые приложения читают ~/.local/share/applications/mimeinfo.cache вместо ~/.config/mimeapps.list, Итак, обновите кеш:

    $ update-desktop-database ~/.local/share/applications/

  10. Протестируйте его в браузере с локальным HTML-файлом.

    <!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Example URL</title>
  </head>
  <body>
    <a href="myprotocol://abcd">myprotocol://abcd</a>
  </body>
</html>

    При первом открытии ссылки Firefox предложит вам найти файл рабочего стола.

    Перейдите к ~/.local/share/applications/ и нажмите myprotocol-handler.desktop,

    Также установите флажок "Запомнить мой выбор для моих протокольных ссылок".

    Это должно выглядеть так, когда вы закончите.

  11. Протестируйте его в браузере с помощью удаленного HTML-файла.

    Существуют некоторые различия в безопасности между локальными и удаленными файлами HTML, поэтому хорошо проверить оба. Вы можете настроить хостинг для этого, или просто использовать Github или аналогичный, но это выходит за рамки этого вопроса.

Источник
Другие вопросы по тегам