debian 9 上的 xdg-open 无法打开浏览器

Question

我决定尝试lxdm（使用fluxbox和xfce），并发现对于许多程序，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

Answer 1

@ user310685 接近了 - 但绝对是错误的。这种修复“工作”，只有当xdg-open是不给“裸”文件路径（即不带前导“文件：//” URI方案和双斜杠）或文件处心积虑的URI（即与领先的“file：//”） . 这两种类型的论点应该xdg-open遵循pcmanfm，但他们不会。

实际错误不是 STDERR 重定向中的错误。相反，脚本编写者混淆了test“and”运算符和shell的进程列表“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（根据上面提到的代码注释）

如果这两个条件都成立，那么脚本会进入一个短块：

1. 调用脚本函数file_url_to_path()以去除任何前导的“file://”部分（作为本地 var file）
2. 如果结果不是绝对路径（即不以“/”开头），则将 CWD 添加到 file
3. 执行 pcmanfm "$file"

为什么原始脚本失败：

如上所述，脚本（错误地）使用“-a”作为“进程列表和操作符”。实际发生的是 shell 运行命令（在 STDOUT 和 STDERR 重定向被“拉出”命令之后，允许它们位于命令字序列中第一个字之后的任何位置）：

pcmanfm --help -a is_file_url_or_path "$1"

这总是成功（除非pcmanfm在 PATH 上不可执行）。命令行 ( -a ..)上的所有额外内容都将通过pcmanfm运行它的--help模式而被忽略。因此，始终执行“作为文件或文件 URL 处理”代码块。当给定一个 URL（带有方案部分）时，file_url_to_path()脚本函数只删除前导的“file://”，截断任何尾随的“#...”片段，并对参数进行 URI 解码（即“%XX”转换为 ASCII）。注意：除非参数以“file:///”开头，否则什么都不做。

例如，OP 的 URL“ https://www.google.com ”没有改变，file_url_to_path()因为它不以“file:///”开头。但是后来的代码认为这个参数是一个“相对路径”，因为它显然不是以“/”开头。因此，它如所述那样在 CWD 前面加上，然后pcmanfm几乎肯定不会找到该修改过的值作为现有的显示路径。相反，它会显示一个错误弹出窗口，如 OP 的问题所示。

修复：

足够简单：对流程链使用正确的语法 AND 运算符：“&&”，如#FIXED#上面的行所示。

@user310685 建议的 HORROR：

@user310685 的提议确实解决了一个问题，有点。发生的情况是 shell 尽职尽责地进行变量扩展，然后尝试执行如下操作：

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

这几乎肯定会产生 shell 重定向错误（除非 CWD 有一个名为“https:”的文件夹（在正确的位置） - 它可以）。该重定向错误会向 STDERR 发送一条消息，然后 shell 继续前进。由于此错误发生在一个if .. else .. fi块内，shell 承担了这一else .. fi部分，这正是 @user310685 想要的。这样，问题就解决了……

但代价是什么？？？

这个不太正确的修复有两个问题：

1. 当实际给定路径或文件方案 URL 时，会执行错误的代码路径（else .. fi部分）。这是因为预期的进程链实际上只是一个（几乎）总是生成 shell 重定向错误的单个进程，该错误被视为if .. ;“false”的条件。这不是SOOOO糟糕，因为那else .. fi块只是推迟工作，另一个叫脚本的功能，open_generic()这是专门用来处理路径和文件的URL（而不是用pcmanfm做工作，而其他一些复杂的代码路径，我没有分析，但我认为做得很好）。可是等等！该HORROR ...
2. 查看pcmanfm --help ...shell 尝试的扩展脚本行。注意 STDERR 的重定向。考虑一下如果使用合法路径（例如“/home/user/precious”）完成此操作会发生什么。OMG尝试探测是否pcmanfm可用然后测试参数是否是一个文件只是覆盖文件！！！再见了珍贵的...