Início / unix / Perguntas / 450200
Accepted
Evil Spork
Asked: 2018-06-17 11:37:50 +0800 CST

xdg-open no debian 9 falha ao abrir o navegador

  • 772

Eu decidi tentar lxdm (estava usando fluxbox e xfce), e descobri que para muitos programas o url handler estava falhando, produzindo esta mensagem de erro; mensagem de erro

Muito estranho, como você pode ver, está anexando o diretório do usuário ao url. O exemplo aqui é do telegram, mas acontece no discord, assim como ao executar a partir da linha de comando; xdg-open https://www.google.comproduz um erro semelhante. xdg-settings get default-web-browsersaída firefox.desktop que funciona como um link tanto no xfce quanto no lxdm. Mais Informações; Eu rodei bash -x nele e...

$ 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

A parte importante parece ser pcmanfm --help -a is_file_url_or_path http://www.google.com, mas esse comando, se é assim que foi usado, não parece fazer muita coisa?

$ 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
debian url

4 respostas

  1. Best Answer

    @ user310685 chegou perto - mas DEFINITIVAMENTE ERRADO. Essa correção "funciona" apenas quando NÃOxdg-open são fornecidos caminhos de arquivo "nu" (ou seja, sem esquema de URI "file://" inicial e barra dupla) ou URIs com esquema de arquivo (ou seja, com o "file://" inicial) . Esses dois tipos de argumento deveriam ter adiado , mas não o farão.xdg-openpcmanfm

    O erro real não é um erro no redirecionamento STDERR. Em vez disso, é que o escritor do script confundiu o testoperador "and" e o conector "and" da lista de processos do shell. O usado (erroneamente) é "-a"; o correto é "&&".

    Como referência, reproduzi a linha de script original, minha correção para essa linha e a sugestão "horror of horrors" de @ 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

    A intenção do if ..; thené dada na linha de script logo acima dele:

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

    Com este comentário em mente, a maneira de entender a if .. thenlinha problemática é:

    1. Teste se pcmanfmé executável (fazendo com que ele relate sua própria ajuda e descartando qualquer STDOUT ou STDERR)
    2. E, execute a função de script is_file_url_or_path()para ver se o "$1"argumento é aceitável pcmanfm(conforme o comentário de código observado acima)

    Se ambas as condições forem válidas, o script fluirá para um bloco curto que:

    1. Chama a função de script file_url_to_path()para remover qualquer parte "file://" principal (como local var file)
    2. Se o resultado NÃO for um caminho absoluto (ou seja, não começar com "/"), coloque o CWD no início do valor defile
    3. Executarpcmanfm "$file"

    Por que o script original falha:

    Conforme observado acima, o script está (erroneamente) usando "-a" como uma "lista de processos e operador". O que realmente acontece é que o shell executa o comando (após os redirecionamentos STDOUT e STDERR serem "retirados" do comando, que podem estar em qualquer lugar na sequência de palavras de comando após a primeira palavra):

    pcmanfm --help -a is_file_url_or_path "$1"

    Isso sempre é bem-sucedido (a menos que pcmanfmnão seja executável no PATH). Todas as coisas extras na linha de comando ( -a ..) são ignoradas ao pcmanfmexecutar seu --helpmodo. Assim, o bloco de código "process as a file or file-URL" é sempre executado. Quando dado um URL (com uma parte de esquema), a file_url_to_path()função de script remove apenas um "file://" inicial, trunca qualquer fragmento "#..." final e também decodifica o argumento em URI (ou seja, "%XX" são convertidos para ASCII). NOTA: A menos que o argumento comece com "file:///", nada é feito.

    Por exemplo, o URL do OP " https://www.google.com " permanece inalterado, file_url_to_path()pois não começa com "file:///". MAS o código posterior considera esse argumento como um "caminho relativo", pois claramente não começa com "/". Assim, ele precede o CWD conforme descrito e, em seguida pcmanfm, quase certamente NÃO encontrará esse valor munged como um caminho existente para exibição. Em vez disso, mostra um pop-up de erro, como na pergunta do OP.

    O conserto:

    Bastante simples: use a sintaxe correta para um operador AND da cadeia de processo: "&&" conforme mostrado na #FIXED#linha acima.

    O HORROR da sugestão de @ user310685:

    O que @user310685 propõe resolve um problema, mais ou menos. O que acontece é que o shell obedientemente faz a expansão da variável e tenta executar algo como:

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

    Isso quase certamente produzirá um erro de redirecionamento de shell (a menos que o CWD tenha uma pasta (no lugar certo) chamada "https:" - o que poderia ). Esse erro de redirecionamento envia uma mensagem para STDERR e, em seguida, o shell segue em frente. Como esse erro ocorreu dentro de um if .. else .. fibloco, o shell assume a else .. fiparte, que é o que @user310685 deseja. Assim, o problema está resolvido...

    MAS A QUE CUSTO???

    Há dois problemas com essa correção não muito correta:

    1. Quando realmente é fornecido um caminho ou uma URL com esquema de arquivo, o caminho de código errado é executado (a else .. fiparte). Isso ocorre porque a cadeia de processo pretendida é realmente apenas um único processo que (quase) sempre gera um erro de redirecionamento de shell que é considerado como a if .. ;condição "falsa". Isso não é tão ruim, já que esse else .. fibloco apenas adia o trabalho para outra função de script chamada open_generic(), projetada para lidar com caminhos e URLs de arquivo (mas não usando pcmanfmpara fazer o trabalho, em vez de algum outro caminho de código complexo que eu não analisei, mas Presumo que faz um trabalho justo). Mas espere! O TERROR ...
    2. Olhe novamente para a pcmanfm --help ...linha de script expandida que o shell tenta. Observe o redirecionamento de STDERR. Considere o que acontece se isso for feito com um caminho legítimo, como "/home/user/precious". OMG A tentativa de sondar se pcmanfmestá disponível e depois testar se o argumento é um arquivo apenas OVERWROTE THE FILE!!! Adeus precioso...
    • 11

  2. Isso para e Debian 10 (buster)também . Há um erro de digitação no script e a solução é a seguinte:LXDExdg-utils 1.1.3-1xdg-open

        --- /usr/bin/xdg-open   2018-05-20 00:18:48.000000000 +0200
+++ /home/klaumi/bin/xdg-open   2018-09-13 15:15:51.630704599 +0200
@@ -928,7 +928,7 @@
 {

     # pcmanfm only knows how to handle file:// urls and filepaths, it seems.
-    if pcmanfm --help >/dev/null 2>&1 -a is_file_url_or_path "$1"; then
+    if pcmanfm --help >/dev/null 2>$1 -a is_file_url_or_path "$1"; then
         local file="$(file_url_to_path "$1")"

         # handle relative paths

    (Observe que &in 2>&1deve ser substituído por $)

    • 2

  3. Confirmado para Debian 10 (buster), LXDE, xdg-utils 1.1.3-1. Parece um bug? Uma opção que não requer edição /usr/bin/xdg-open:

    • Você pode pedir ao xdg-open para usar um manipulador de ambiente de desktop diferente (ref 1 ): XDG_CURRENT_DESKTOP=gnome xdg-open https://www.google.com

    • 1

  4. A correção Seiji Adachi que ele chama de temporária funciona bem para mim https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906766

    • 0

relate perguntas