SUMMARY GNU coretils outputs file URLs with a hostname when using "ls --hyperlink", e.g. "file://myhost/tmp". Clicking links like these does nothing, but if the host name is removed they work. STEPS TO REPRODUCE 1. Edit the current profile and turn on "Allow escape sequences for links" 2. ls --hyperlink 3. ctl + click a file or directory or 1. echo file://$(hostname)/tmp 2. ctl + click the output or 1. echo file://localhost/tmp 2. ctl + click the output OBSERVED RESULT Nothing happens. EXPECTED RESULT The file or directory is opened in the correct application. This does work properly for file:///tmp , but doesn't work for file://localhost/tmp . It also works for file://tmp , which it probably shouldn't SOFTWARE/OS VERSIONS Linux: 6.5.0 KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10
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.