| Summary: | ls --hyperlink links (file URLs with a host name) do not work | ||
|---|---|---|---|
| Product: | [Applications] konsole | Reporter: | derikson3 |
| Component: | general | Assignee: | Konsole Developer <konsole-devel> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | bugs, fanzhuyifan, yury |
| Priority: | NOR | ||
| Version First Reported In: | 24.12.1 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| URL: | https://bugs.gentoo.org/941194 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
derikson3
2024-03-11 22:14:34 UTC
Hello, I'm the maintainer of Midnight Commander. We have recently started emitting OSC 7 sequences with "file://" information about the current directory to the terminal. We emit host information, because this way the terminal can discern, whether or not the link pertains to the current host (or is, for example, pointing to a machine on the ssh connection). Unfortunately, Konsole (I've checked the latest on Fedora 41) doesn't properly parse host information and forwards the host part to Dolphin. In turn, Dolphin fails to start reporting that "/host/foo/bar" is not a valid path. If we remove the host from the sequence, then Konsole handles it correctly. However, the presence of the host is standard-compliant (see https://datatracker.ietf.org/doc/html/rfc8089) and we also don't want to lose the advantage of distinguishing the hosts as noted above. Other terminal emulation engines (VTE) seem to be able to handle the host just fine. I would appreciate if you could please fix Konsole as well. A similar bug was recently reported against LibreOffice and fixed there: https://bugs.documentfoundation.org/show_bug.cgi?id=107461 . Our bug report can be found here: https://midnight-commander.org/ticket/4614 . Gentoo bug report can be found here: https://bugs.gentoo.org/941194 . Many thanks! All the best, Yury I'd just like to add a few details to this: a more reliable repro, a document showing what Konsole should do, and a possible explanation for what it currently does. The following steps to reproduce are modified to ensure that Konsole's own filename detection feature does not interfere: 1. Enable "Allow escape sequences for links", in the current console profile. 2. $ touch ~/Documents/example.txt 3. $ (cd ~/Documents/ && ls --hyperlink=always example.txt) 4. Ctrl+click on "example.txt". Konsole should open example.txt in a text editor, but instead it pops up a dialog which says: > The file or folder //[your hostname]/home/[your username]/Documents/example.txt does not exist. The following page states that ls is doing the correct thing, and file:// URLs produced using OSC 8 escape sequences should always have a hostname component. https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda#file-uris-and-the-hostname Is this actually exposing a bug in KIO? It appears to have special handling for the current hostname, along with "localhost", in file:// URLs, but this special handling does not do the right thing: $ kioclient stat file://localhost/etc kioclient: The file or folder //localhost/etc does not exist. $ kioclient stat file://otherhost/etc kioclient: The file or folder smb://otherhost/etc does not exist. Other hostnames cause the URL to be treated as smb:// URLs, while "localhost" and the system's own hostname are handled specially. However, somehow, the way in which they are handled specially is that they are converted to directory names. This has the curious consequence that you can "fix" hyperlinks in Konsole by doing `sudo ln -s / /$(hostname)`. I am not recommending this as a solution - I'm using it as a demonstration that the hostname really is being interpreted as a directory name. |