bug: --hyperlink does not work with filenames with spaces

[xxyxxyxyx1]

• The version of eza being used (eza --version): v0.15.0 [+git]
• The command-line arguments you are using: --hyperlink
• Your operating system and hardware platform: M1 Max, macOS 13.5, zsh 5.9; kitty 0.30.1 or wezterm 20230712-072601-f4abf8fd

When the --hyperlink flag is used, filenames are generally clickable and open the file in a GUI application. However, if the filename contains a space, nothing happens.

For example, the first file in this directory will open on click, while the second does not:

$ eza --hyperlink
some_file.pdf  'some file.pdf'

If I use GNU ls --hyperlink, or lsd --hyperlink always, both files are click-openable, as expected.

This bug occurs in both kitty and wezterm terminal emulators, so I think it's an eza problem.

[cafkafk]

works fine for me on kitty on version 0.14.2, maybe it's a 0.15 thing?

[cafkafk]

Just tried on 0.15.0, can't reproduce on kitty

[xxyxxyxyx1]

Thank you for checking. Do you have any suggestions, or is there further information I can provide?

[cafkafk]

Idk tbh... This might be a MacOS thing, in which case you'll have to hope for one of the resident MacOS devs to stumble upon this and look into it

[hasecilu]

I tried to reproduce on v0.15.0 on Arch Linux using Alacritty and worked just fine, both with and without --icons.

[xxyxxyxyx1]

I wonder if macOS is more sensitive to the escape sequence or quoting? I think it's the open macOS command that inspects the file and chooses a GUI application with which to open it. Maybe open is less robust than the linux equivalent.

In lsd, it doesn't look like macOS receives different treatment than other platforms. The link format is:
format!("\x1B]8;;{url}\x1B\x5C{name}\x1B]8;;\x1B\x5C")
https://github.com/lsd-rs/lsd/blob/36c8f26a1780c4eea9656fc1bf0d409c610b8949/src/meta/name.rs#L123C40-L123C40

In eza, it is done here:

eza/src/output/file_name.rs

Line 365 in bba97b5

fn escaped_file_name<'unused>(&self) -> Vec<ANSIString<'unused>> {

I don't know any rust, so I cannot tell if these would result in same final string being sent to the terminal.

[xxyxxyxyx1]

Today I updated to 0.17.0 and I no longer observe this bug.

[cafkafk]

Today I updated to 0.17.0 and I no longer observe this bug.

Awesome!