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

Question 1

@user310685 已经接近了 - 但绝对是错误的。该修复仅在以下情况下“有效xdg-open”不是给定“裸”文件路径（即没有前导“file://”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行的方法是：

测试是否pcmanfm可运行（通过让它报告自己的帮助，并丢弃任何 STDOUT 或 STDERR）
并且，运行脚本函数is_file_url_or_path()以查看"$1"参数是否可接受pcmanfm（根据上面提到的代码注释）

如果这两个条件都成立，则脚本将流入一个短块：

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

为什么原始脚本失败：

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

pcmanfm --help -a is_file_url_or_path "$1"

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

例如，OP 的 URL“https://www.google.com" 不变，file_url_to_path()因为它不以“file:///”开头。但后面的代码会将此参数视为“相对路径”，因为它显然不是以“/”开头。因此，它如所描述的那样预先考虑 CWD，然后pcmanfm几乎肯定不会找到该 munged 值作为要显示的现有路径。相反，它显示一个错误弹出窗口，如OP的问题所示。

修复：

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

@user310685 的建议的可怕之处：

@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 想要的。这样，问题就解决了……

但代价是什么？

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

当实际给出路径或文件架构 URL 时，会执行错误的代码路径（else .. fi部分）。这是因为预期的进程链实际上只是一个（几乎）总是生成 shell 重定向错误的进程，该错误被视为if .. ;“假”的条件。这不苏奥不好，因为该else .. fi块只是将工作推迟到另一个名为的脚本函数，open_generic()该函数旨在处理路径和文件 URL（但不用于pcmanfm完成工作，而是使用其他一些复杂的代码路径，我没有分析，但我认为确实如此）一份公平的工作）。可是等等！这恐怖...
回头看看pcmanfm --help ...shell 尝试的扩展脚本行。请注意 STDERR 的重定向。考虑一下如果使用合法路径（例如“/home/user/precious”）完成此操作会发生什么。我的天啊尝试探测是否pcmanfm可用，然后测试参数是否是一个文件覆盖文件！！！再见了，珍贵的...

Answer