ls --hyperlink shows error when clicked

[munzirtaha]

What Operating System(s) are you seeing this problem on?

Linux Wayland

Which Wayland compositor or X11 Window manager(s) are you using?

KDE

WezTerm version

wezterm 20240922-151228-2b76c63b

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

$ ls --hyperlink

Shows clickable file and folder names, but when I click on any folder I get:

Error - KIO Client The file or folder //lenovo/home/me/Pictures does not exist.

After clicking OK to the error, it will open the file or folder successfully.

> ls --hyperlink |cat -v |rg Pictures
^[]8;;file://lenovo/home/me/Pictures^GPictures^[]8;;^G

To Reproduce

$ ls --hyperlink

and click any file or folder name

Configuration

no config

Expected Behavior

No error

Logs

No response

Anything else?

No response

[loops]

Hi munzirtaha,

This isn't a Wezterm bug. The ls --hyperlink feature, always outputs a file:// protocol URL that includes the hostname.
The justification being that you might be ssh'd into a remote host etc. But unfortunately, the KDE KIO client apparently doesn't handle such URLs correctly.

Think you'll have to report a bug with KDE.

Edit: you might actually be able to make it work with a custom event handler, but the
details will depend on your machine; something along the lines of:

wezterm.on("open-uri", function(window, pane, uri)
 local nuri, n = string.gsub(uri, "file://lenovo", "file://")
 if n == 1 then
	window:perform_action(
		wezterm.action.SpawnCommandInNewWindow({
			args = { "kioclient", "exec", nuri },
		}),
		pane
	)
	return false
 end
end)

[munzirtaha]

Thanks a lot for the quick reply. In the beginning, I also thought wezterm has nothing to do with this issue because it's between ls and kio, but then I tried konsole and kitty and both worked. I check the output in all terminals and it's exactly the same:

ls -d Pictures |cat -v
^[[0m^[[01;34m^[]8;;file://lenovo/home/me/Pictures^GPictures^[]8;;^G^[[0m

If KDE KIO client doesn't handle such URLs correctly, how come it handles them in other terminals? How come even in wezterm it handles them correctly after showing the error?

[loops]

If KDE KIO client doesn't handle such URLs correctly, how come it handles them in other terminals? How come even in wezterm it handles them correctly after showing the error?

Good point. Turns out Wezterm will keep trying each of these methods in turn until success:

 xdg-open, gio, gnome-open, kde-open, wslview. 

So, it keeps going after the initial error that you see. This suggests another
option you have to fix things up, you could make a custom xdg-open to
handle the issue too.

I

[munzirtaha]

But none of these commands would open the hyperlink in KDE

> kde-open file://lenovo/home/me/Pictures
The file or folder //lenovo/home/me/Pictures does not exist.

However, after the error, dolphin opened the folder in my system. What's the logic wezterm has after those commands fail? Who launched dolphin?

I don't know what other terminals do, but isn't it easy for wezterm to fix it by removing the file:// before passing it to xdg-open and its brothers?

[loops]

What's the logic wezterm has after those commands fail? Who launched dolphin?

As far as I can tell, Wezterm won't do anything else after those commands.
If you want to prove it to yourself, temporarily rename those commands
on your system, and try again.

but isn't it easy for wezterm to fix it by removing the file://

Yes, it'd be easy for it to remove file://localhost and file://$HOSTNAME
Although it might cause some minor breakage on existing systems
that expect such links.

[munzirtaha]

I tested this as you said and it turned out the gio is the only one which managed to open the "file://$hostname" link. So, my simple understanding is wezterm shouldn't return an error before testing all of them and only in case all failed. Currently, it tries kde-open, emitting an error, then tries xdg-open, emits an error, then tries gio, and gio successfully opens my default opener which turned out to be dolphin. Does this make sense?

[loops]

Close, but xdg-open is being called first. It detects that you're running KDE, so it calls kde-open, which generates an error. Wezterm calls gio next. The errors you see are not generated by Wezterm, it's just the error output generated by kde-open. But i'm not sure how you would see those, unless you are starting Wezterm at a command line.

[munzirtaha]

Thanks for the fruitful discussion. I agree the error is not generated by wezterm but why do you assume I shouldn't see the errors? I started wezterm from the menu not from the command line, but I don't think this is relevant because it's a pop-up dialog box from a child process.

I now checked the code and even if you have if status.success(), the user would still get the error because it's not generated by xdg-open and brothers. I checked this from the command line and the error shows

xdg-open file://$hostname/home/$USER/Pictures 2> /dev/null

To summarize my evolving understanding

1. wezterm can fix this by not relying on these tools and remove the file schema and the hostname part in case of localhost only, which I guess how other terminals handled it. This shouldn't break anything but it seems like reinventing the wheel.
2. I would open a bug regarding kde-open if there is no one yet and see how they respond.
3. Having wezterm calling kde-open, gnome-open, and may be wslview doesn't make sense because xdg-open is already calling them

[loops]

Ugh! So up until this point, I didn't understand that you were getting a popup window in your face,
I thought it was just an error message scrolling by. That is unacceptable for sure.

why do you assume I shouldn't see the errors?

I've never seen an interactive window displayed for any of these command-line utilities on any system ever. See something new every day :-)

If it was my system, and everything else being equal, I'd just uninstall whatever package provides kde-open,
since it seems very broken and unhelpful. But short of that, it would be pretty easy to rename it to kde-open-orig,
and create a new kde-open, that alters the url before passing it to kde-open-orig.

Edit: uninstalling kde-open is a bad idea, since it would break xdg-open on your system too.

Or you can use the wezterm lua "open-uri" handler from a few messages back to avoid the default
Wezterm handling, and just do exactly what you want instead.

I would open a bug regarding kde-open if there is no one yet and see how they respond.

That would be great. But I think you have everything you need to make your system work well in the interim.

Having wezterm calling kde-open, gnome-open, and may be wslview doesn't make sense because xdg-open is already calling them

xdg-open doesn't exist on every system. And if xdg-open is successful, the others are never called anyway.

[munzirtaha]

I would open a bug regarding kde-open if there is no one yet and see how they respond.

That would be great. But I think you have everything you need to make your system work well in the interim.

Yes, with your help I already made my system work properly in different ways. I even, for playing sake, removed all those candidates and compiled wezterm with gio only and it worked. But I have a nasty habit of chasing bugs to help make open source software more friendly for users who cannot fix things themselves. Let's leave this open till I see the response of the KDE people.

[munzirtaha]

For reference, I found a bug already open at https://bugs.kde.org/show_bug.cgi?id=461756 two years ago.

I have one suggestion that might be very trivial but solves the problem elegantly. Why not you just change the order and put the best candidate gio at the top. Unlike xdg-open, kde-open, and gnome-open, it works in KDE, GNOME, and other DE's, beside it's also a dependency of most DE's, so it's guaranteed to be installed in more systems.