[Kalkihe]

Ich habe im Grunde das selbe Problem wie hier beschrieben: https://forum.lxde.org/viewtopic.php?f=8&t=39450

Ich nutze LXDE unter Debian und jedes mal wenn ich bspw in einem PDF auf einen Link klicke, passiert das gezeigt, anstatt dass der Browser geöffnet wird. Wenn ich auf i3 wechsle, funktioniert das einwandfrei. Kann ich das irgendwo einstellen, mit was URLS verarbeitet werden sollen?

Unter lxsession-default-... hab ich den Browser bereits als Standardapplikation festgelegt. Es passiert aber auch nur aus gewissen Programmen heraus, aus Thunderbird geht es bspw, aus Telegram und weiteren nicht.

[foobar]

jedes mal wenn ich bspw in einem PDF auf einen Link klicke, passiert das gezeigt, anstatt dass der Browser geöffnet wird.

Das ist irgendwie kein richtiger Satz. Ich vermute, du möchtest den Browser als Standard-PDF-Betrachter einrichten?

In dem Fall: Ich bin kein LXDE-Experte, meines Wissens benutzt es XDG. Probiere also mal xdg-mime.

Beispiel:

$ xdg-mime query default application/pdf
evince.desktop
$ xdg-mime default atril.desktop application/pdf
$ xdg-mime query default application/pdf
atril.desktop

Zur Erläuterung: Der erste Befehl fragt die aktuelle Standardanwendungen für PDFs ab. Das Ergebnis lautet: Evince. Dann setzt der zweite Befehl Atril als neuen PDF-Betrachter, was der dritte Befehl nochmal überprüft. Für Details: man xdg-mime.

Sollte das nicht helfen, kannst du nochmal in folgenden Dateien gucken, ob da was anderes festgelegt ist:

• ~/.local/share/applications/defaults.list
• ~/.config/mimeapps.list

EDIT: Evtl. musst du dich nach dem Ändern noch einmal ab- und wieder anmelden, damit die Einstellungen wirksam werden.

[Kalkihe]

Das ist nicht ganz mein Problem.

Ich klicke in browser-fremden Anwendungen immer wieder auf URLs. Bei Applikationen wie evince oder Thunderbird funktioniert es einwandfrei, dass der Befehl an den Browser gesendet wird und dieser dann den Link öffnet. Wenn ich dies aber von zathura oder von Telegram aus mache, kommt ein Fehler in der Art:
[Bild: OYtdeJ9.png]

Dies würde ich gerne ändern. Den Browser habe ich bereits als Standardapplikation für Internet in lxsession-default-apps festgelegt.

[foobar]

Naja, in dem Screenshot liegt das vermutlich daran, dass der Link keine wohlgeformte URL ist. Da steht „https:/www” anstelle von „https://www”. Und natürlich erkennt das System das dann nicht als Web-URL und versucht daher, es als lokale Datei zu öffnen.

Ansonsten mache doch mal ein strace und ermittle, wie diese Programme den Link zu öffnen versuchen.

[Kalkihe]

Ja okay, der Screenshot ist auch nicht von mir. Aber bei mir passiert das wie von mir beschrieben bei normal funktionierenden URLs.

Kann ich bei strace nach was suchen? Den Output von 35000 Zeilen durch zu schauen halte ich ein wenig für nicht zielführend. Aber Suche nach url oder http darin hat nichts gefunden.

[foobar]

Kann ich bei strace nach was suchen? Den Output von 35000 Zeilen durch zu schauen halte ich ein wenig für nicht zielführend. Aber Suche nach url oder http darin hat nichts gefunden.

$ strace -o debug.log -f zathura datei-mit-hyperlink.pdf

Dann auf den Link klicken und wieder schließen. Anschließend erhalte ich bei mir (Mint 19.3):

$ grep 'https' debug.log
32469 execve("/usr/local/sbin/xdg-open", ["xdg-open", "https://www.worldofplayers.de/"], 0x7ffde6207b60 /* 50 vars */) = -1 ENOENT (No such file or directory)
32469 execve("/usr/local/bin/xdg-open", ["xdg-open", "https://www.worldofplayers.de/"], 0x7ffde6207b60 /* 50 vars */) = -1 ENOENT (No such file or directory)
32469 execve("/usr/sbin/xdg-open", ["xdg-open", "https://www.worldofplayers.de/"], 0x7ffde6207b60 /* 50 vars */) = -1 ENOENT (No such file or directory)
32469 execve("/usr/bin/xdg-open", ["xdg-open", "https://www.worldofplayers.de/"], 0x7ffde6207b60 /* 50 vars */ <unfinished ...>
32471 execve("/usr/bin/exo-open", ["exo-open", "https://www.worldofplayers.de/"], 0x55af03c4f320 /* 50 vars */ <unfinished ...>
32475 execve("/usr/lib/x86_64-linux-gnu/xfce4/exo-2/exo-helper-2", ["/usr/lib/x86_64-linux-gnu/xfce4/"..., "--launch", "WebBrowser", "https://www.worldofplayers.de/"], 0x7ffc60ec7c50 /* 50 vars */ <unfinished ...>
32476 execve("/usr/local/sbin/palemoon", ["palemoon", "https://www.worldofplayers.de/"], 0x7fffb773d070 /* 50 vars */) = -1 ENOENT (No such file or directory)
32476 execve("/usr/local/bin/palemoon", ["palemoon", "https://www.worldofplayers.de/"], 0x7fffb773d070 /* 50 vars */) = -1 ENOENT (No such file or directory)
32476 execve("/usr/sbin/palemoon", ["palemoon", "https://www.worldofplayers.de/"], 0x7fffb773d070 /* 50 vars */) = -1 ENOENT (No such file or directory)
32476 execve("/usr/bin/palemoon", ["palemoon", "https://www.worldofplayers.de/"], 0x7fffb773d070 /* 50 vars */ <unfinished ...>

Man sieht, wie er zuerst den Suchpfad nach xdg-open abklappert, bis er es schließlich findet. xdg-open reicht es dann durch an exo-open (weil ich XFCE benutze) und das öffnet meinen Standardbrowser (Palemoon) mit der URL.

Zathura scheint also xdg-open zu verwenden und der nächste Test wäre, ob es funktioniert, wenn du es direkt von der Shell aus aufrufst:

$ xdg-open 'https://www.worldofplayers.de'

Was bei mir dann auch, wenig überraschend, problemlos geht.

[Kalkihe]

Okay, dank deiner Ausführungen konnte ich diesen Schritt mal überspringen und habe es direkt mit xdg-open probiert. Hier erhalte ich eben wieder diese Fehlermeldung:

/home/kalkihe/https:/www.worldofplayers.de: Datei oder Verzeichnis nicht gefunden

Bedeutet also wohl, dass es an xdg-open liegt.

Was mir gerade auffällt: Bei mir fehlt nun ebenfalls der zweite / nach dem https:. Irgendwo scheint da was falsch übermittelt zu werden, obwohl ich den Befehl von dir kopiert habe.

[foobar]

Hmm... ich habe einen Verdacht.

Probiere mal:

XDG_CURRENT_DESKTOP=X-Generic xdg-open https://www.worldofplayers.de

Welche Version der xdg-utils benutzt du?

[Kalkihe]

Dies funktioniert. Ich verwende Version 1.1.3-1

[foobar]

Dies funktioniert. Ich verwende Version 1.1.3-1

Dann leidest du (vermutlich) unter einem Bug von xdg-open in dieser Version. Dabei erkennt er URLs nicht korrekt und versucht, sie mit dem Dateimanager (pcmanfm) zu öffnen. Da der davon ausgeht, eine Datei zu kriegen, und da doppelte Schrägstriche in Dateinamen keinen Sinn haben, kürzt er das vermutlich dann automatisch auf einen Schrägstrich. Und liefert so oder so einen Fehler, weil es die Datei nicht gibt.

Um das Problem zu beheben, legst du am besten eine Kopie an, damit deine Korrektur bei evtl. Updates nicht überschrieben wird (erfordert root):

# cp /usr/bin/xdg-open /usr/local/bin

Und dann suchst du in /usr/local/bin/xdg-open die Zeile:

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

und änderst sie wie folgt:

if pcmanfm --help >/dev/null 2>&1 && is_file_url_or_path "$1"; then

Dann neustarten und sicherstellen, dass 'which xdg-open' auf die neue Version in /usr/local/bin verweist. Mit etwas Glück funktioniert es dann.

[Kalkihe]

Okay, das funktioniert so, vielen Dank!

Du sprichst ja von einem Bug in dieser Version. Bin ich denn auf der aktuellen Version bzw. gibt es eine andere Version, die ich (am besten über apt) installieren kann, damit dieser manuelle Fix obsolet wird?

[foobar]

Du sprichst ja von einem Bug in dieser Version. Bin ich denn auf der aktuellen Version bzw. gibt es eine andere Version, die ich (am besten über apt) installieren kann, damit dieser manuelle Fix obsolet wird?

Im Git-Repository des Projekts ist es bereits behoben, aber Debian scheint das noch nicht paketiert zu haben. Mein Mint verwendet noch Version 1.1.2. Da ist der Fehler aber auch nicht drin. War offenbar ein spezielles Problem von 1.1.3.

Sollte irgendwann eine neue Version der xdg-utils via apt kommen, kannst du mal gucken, ob der Fehler behoben wurde und dann deine Kopie unter /usr/local/bin wieder löschen. Damit du nicht mit einer ggf. veralteten Kopie des Script weiter arbeitest.

[Kalkihe]

Im Git-Repository des Projekts ist es bereits behoben, aber Debian scheint das noch nicht paketiert zu haben. Mein Mint verwendet noch Version 1.1.2. Da ist der Fehler aber auch nicht drin. War offenbar ein spezielles Problem von 1.1.3.

Sollte irgendwann eine neue Version der xdg-utils via apt kommen, kannst du mal gucken, ob der Fehler behoben wurde und dann deine Kopie unter /usr/local/bin wieder löschen. Damit nicht mit einer ggf. veralteten Kopie des Script weiter arbeitest.

Ah ich habe gerade mal geschaut. v.1.1.3 ist tatsächlich auch die aktuellste, für die ein Release vorliegt. Also kann so natürlich nichts paketiert werden, wenn das Team keine neue Version raushaut (seit 10.05.2018). Ich werde vielleicht mal ein Issue dazu anlegen.

[foobar]

Also kann so natürlich nichts paketiert werden, wenn das Team keine neue Version raushaut (seit 10.05.2018).

Der Debian-Maintainer könnte durchaus hergehen und den Bug eigenständig beheben. Im Paketbaumechanismus von Debian/dpkg ist es explizit vorgesehen, die ursprünglichen Quellen noch zu verändern, bevor sie kompiliert und paketiert werden.

[Lookbehind]

$ apt-cache show xdg-utils | grep Maintainer
Maintainer: Debian freedesktop.org maintainers <pkg-freedesktop-maintainers@lists.alioth.debian.org>

... nur falls es wen interessiert.