Debian 9のxdg-openはブラウザを開くことができません

Debian 9のxdg-openはブラウザを開くことができません

私は(Fluxboxとxfceを使用して)lxdmを試すことにしましたが、多くのプログラムでURLハンドラがこのエラーメッセージで失敗することがわかりました。 エラーメッセージ

ご覧のとおり、これは奇妙です。ユーザーディレクトリをURLの前に追加します。ここの例はテレグラムからのものですが、コマンドラインで実行されたときだけでなく、不一致でもxdg-open https://www.google.com同様のエラーが発生します。 xdg-settings get default-web-browser出力 firefox.desktop は xfce と lxdm のリンクとして使用できます。より多くの情報; bash -xを実行しました...

$ bash -x /usr/bin/xdg-open http://www.google.com
+ check_common_commands http://www.google.com
+ '[' 1 -gt 0 ']'
+ parm=http://www.google.com
+ shift
+ case "$parm" in
+ '[' 0 -gt 0 ']'
+ '[' -z '' ']'
+ unset XDG_UTILS_DEBUG_LEVEL
+ '[' 0 -lt 1 ']'
+ xdg_redirect_output=' > /dev/null 2> /dev/null'
+ '[' xhttp://www.google.com '!=' x ']'
+ url=
+ '[' 1 -gt 0 ']'
+ parm=http://www.google.com
+ shift
+ case "$parm" in
+ '[' -n '' ']'
+ url=http://www.google.com
+ '[' 0 -gt 0 ']'
+ '[' -z http://www.google.com ']'
+ detectDE
+ unset GREP_OPTIONS
+ '[' -n LXDE ']'
+ case "${XDG_CURRENT_DESKTOP}" in
+ DE=lxde
+ '[' xlxde = x ']'
+ '[' xlxde = x ']'
+ '[' xlxde = x ']'
+ '[' xlxde = xgnome ']'
+ '[' -f /run/user/1000/flatpak-info ']'
+ '[' xlxde = x ']'
+ DEBUG 2 'Selected DE lxde'
+ '[' -z '' ']'
+ return 0
+ case "${BROWSER}" in
+ case "$DE" in
+ open_lxde http://www.google.com
+ pcmanfm --help -a is_file_url_or_path http://www.google.com
++ file_url_to_path http://www.google.com
++ local file=http://www.google.com
++ echo http://www.google.com
++ grep -q '^file:///'
++ echo http://www.google.com
+ local file=http://www.google.com
+ echo http://www.google.com
+ grep -q '^/'
++ pwd
+ file=/home/nesmerrill/.local/share/applications/http://www.google.com
+ pcmanfm /home/nesmerrill/.local/share/applications/http://www.google.com
+ '[' 0 -eq 0 ']'
+ exit_success
+ '[' 0 -gt 0 ']'
+ exit 0

ところで重要な部分はpcmanfm --help -a is_file_url_or_path http://www.google.com命令をこのように使用すると何も起こらないようだという点なのですが?

$ pcmanfm --help -a is_file_url_or_path http://www.google.com
Usage:
  pcmanfm [OPTION…] [FILE1, FILE2,...]  

Help Options:
  -h, --help                   Show help options
  --help-all                   Show all help options
  --help-gtk                   Show GTK+ Options

Application Options:
  -p, --profile=PROFILE        Name of configuration profile
  -d, --daemon-mode            Run PCManFM as a daemon
  --no-desktop                 No function. Just to be compatible with nautilus
  --desktop                    Launch desktop manager
  --desktop-off                Turn off desktop manager if it's running
  --desktop-pref               Open desktop preference dialog
  --one-screen                 Use --desktop option only for one screen
  -w, --set-wallpaper=FILE     Set desktop wallpaper from image FILE
  --wallpaper-mode=MODE        Set mode of desktop wallpaper. MODE=(color|stretch|fit|crop|center|tile|screen)
  --show-pref=N                Open Preferences dialog on the page N
  -n, --new-win                Open new window
  -f, --find-files             Open a Find Files window
  --role=ROLE                  Window role for usage by window manager
  --display=DISPLAY            X display to use

ベストアンサー1

@user310685 は近かったけど確かに間違っていた修正は、次の場合にのみ「動作xdg-open」します。いいえ「デフォルト」ファイルパス(たとえば、先行する「file://」URIスキームとデュアルスラッシュなし)またはファイルスキームURI(例えば、先行する「file://」を含む)が提供されます。どちらの種類の引数も後にxdg-open続く必要がありますpcmanfmが、そうではありません。

実際のエラーはSTDERRリダイレクトのエラーではありません。代わりに、スクリプトはtest「and」演算子をシェルのプロセスリスト「and」コネクタと混同します。 (無効な)使用は「-a」、正しい使用は「&&」です。

参考までに、元のスクリプト行、その行に対する修正、および@user310685の「恐怖の恐怖」提案をコピーしました。

#ORIG#   if pcmanfm --help >/dev/null 2>&1 -a is_file_url_or_path "$1"; then
#FIXED#  if pcmanfm --help >/dev/null 2>&1 && is_file_url_or_path "$1"; then
#HORROR# if pcmanfm --help >/dev/null 2>$1 -a is_file_url_or_path "$1"; then

その意図はif ..; then上記のスクリプト行に示されています。

# pcmanfm only knows how to handle file:// urls and filepaths, it seems.

この意見を考慮すると、問題のある行を理解する方法はif .. then次のとおりです。

  1. 実行可能かどうかをテストしますpcmanfm(自己ヘルプを報告し、STDOUTまたはSTDERRを削除することによって)。
  2. 次にスクリプト機能を実行して、パラメータが許可されていることをis_file_url_or_path()確認します(上記のコードコメントに基づいています)。"$1"pcmanfm

両方の条件が true の場合、スクリプトは短いブロックに流れます。

  1. 先行する「file://」部分を削除するスクリプト関数を呼び出しますfile_url_to_path()(ローカルvarでfile)。
  2. 結果が絶対パスでない場合(例: "/"で始まらない)、次の値にCWDを追加します。file
  3. 実装するpcmanfm "$file"

元のスクリプトが失敗する理由:

上記のように、スクリプトは「プロセスリスト」に「-a」を(誤って)使用します。そして実際に起こるのは、シェルがコマンドを実行することです(STDOUTとSTDERRリダイレクトがコマンドから「削除」され、コマンドワードシーケンスの最初の単語の後にどこにでも表示できるようにした後)。

pcmanfm --help -a is_file_url_or_path "$1"

これいつも成功(pcmanfmPATHで実行可能でない場合)。モードで実行すると、コマンドライン()のすべての追加エントリは-a ..無視されます。したがって、「ファイルまたはファイルURLとして処理」コードブロックは次のようになります。pcmanfm--helpいつも処刑される。 URL(スキーム部分を含む)が提供されている場合、スクリプトfile_url_to_path()機能は単に先行する "file://"を削除し、末尾の "#..."フラグメントを切り捨て、パラメータをURIデコード(たとえば "%XX")します。 ASCII)。注:引数が「file:///」で始まらないと、何もしません。

たとえば、OPのURLは 'https://www.google.comfile_url_to_path()" は"file:///"で始まらないため、変更されません。しかし、隠しコードは、このパラメータが明らかに「/」で始まらないため、「相対パス」として扱います。したがって、説明されているようにCWDを追加してから、表示するpcmanfm既存のパスでその値を見つけることができないことはほぼ確実です。代わりに、OPの質問に示すようにエラーポップアップが表示されます。

修理する:

#FIXED#とても簡単です。上記の行に示すように、プロセスチェーンに正しいAND演算子構文「&&」を使用してください。

@user310685の提案の恐ろしい点は次のとおりです。

@user310685の提案で問題が修正されました。何が起こるかは、シェルが忠実に変数拡張を実行してから、次のことを試してみることです。

pcmanfm --help >/dev/null 2>https://www.google.com -a is_file_url_or_path https://www.google.com

CWDに「https:」(正しい場所に)というフォルダがない限り、これはほぼ確実にシェルリダイレクトエラーを生成します。できる)。リダイレクトエラーはSTDERRにメッセージを送信し、シェルは続行されます。このエラーはif .. else .. fiブロック内で発生するため、シェルはelse .. fi@user310685が望んでいた部分を占めます。このようにして問題は解決されます。

しかし、どのような対価を払うのでしょうか?

あまり正確ではないこの修正には2つの問題があります。

  1. 実際、パスまたはファイルスキーマのURLを入力すると、間違ったコードパス(else .. fi一部)が実行されます。これは、予想されるプロセスチェーンが実際には(ほぼ)常にif .. ;「偽」条件として処理されるシェルリダイレクトエラーを生成する1つのプロセスであるためです。これはないスオ良くありません。ブロックは、パスとファイルのURLを処理するように設計された他のelse .. fiスクリプト関数でタスクを延期するためです(ただし、タスクを実行するために使用されず、代わりに分析されなかった他の複雑なコードパスを使用します)。しかし、私はそれが公正な仕事だと思います)。open_generic()pcmanfmしかし、待って!これ恐怖...
  2. pcmanfm --help ...シェルが試みている拡張スクリプト行をもう一度見てください。 STDERRのリダイレクトに注意してください。 「/home/user/precious」などの正当なパスを使用してこれを行った場合は、何が起こるのかを考えてみてください。利用可能かどうかを検出pcmanfmし、パラメータがファイルかどうかをテストします。ファイルを上書き! ! !こんにちは、大切な...

おすすめ記事