Nushell ls gives clickable links in its result, resulting in a technical correct, but perhaps a bit unexpected result.

[trondhe]

I was going to rename some symlinks for clang-18 to just clang after using the install scripts from llvm.
When I use nushell + ripgrep to search for the existence of files, I got these interesting double results.
clangd resulted in clangdclangd.

I did an issue in nushell here: nushell/nushell#12255

So its technically not a bug anywhere as I understand it, but it gives a bit unexpected result perhaps?
Any thoughts?

[BurntSushi]

I have absolutely no idea what you're talking about. I read the linked issue and I still don't understand.

Please provide a set of commands that I can run along with actual output and expected output.

[BurntSushi]

Cannot reproduce.

[ltrzesniewski]

Repro without nushell:

• mkdir foo
• ls --hyperlink | rg --no-config 'foo'

This happens because ripgrep doesn't remove ANSI escape codes from its input, and foo is printed twice by ls --hyperlink, but only one of those is supposed to be visible (see the hyperlink spec).

Since ripgrep outputs a reset code after each result, which also happens inside the hyperlink URI, I suppose this breaks the terminal hyperlink.

[trondhe]

So then the bug is actually with Pop OS default terminal emulator (GNOME 3.44.0). Since you couldnt reproduce I also tested wezterm. Both are correct, while GNOME gives this bug.

Sorry for wasting your time, I should have tested that as well first before asking!

edit: Or, no matter what the problem is, I have too little knowledge on how terminal emulators and such works too be able to guide myself better, so I am wandering a bit blind here.

[BurntSushi]

Yes, okay, @ltrzesniewski's comment helped me figure this out. It's not just ls --hyperlink, but also ripgrep's color configuration. In particular, you report that this happens with ripgrep and not grep. That is likely because you don't have colors enabled for grep. Moreover, ls --hyperlink probably shouldn't be used at all. It should be ls --hyperlink=auto. The former forces hyperlinks to be written, where as the latter will suppress them when piping ls to some other tool. That's the right default. See:

$ ls | rg foo
foo
$ ls --hyperlink | rg foo
foofoo
$ ls --hyperlink=auto | rg foo
foo
$ ls --hyperlink | rg foo --color=never
foo
$ ls --hyperlink | grep foo
foofoo
$ ls --hyperlink=auto | grep foo
foo
$ ls --hyperlink | grep foo --color=never
foo

The problem here really isn't that "ripgrep doesn't remove ANSI escapes." grep doesn't either. Neither tool does that, and arguably they shouldn't, although this can lead to confusing results because ANSI escapes don't really compose well, as demonstrated here. But this is why --hyperlink=auto and --colors=auto should be the default.

[fdncred]

@BurntSushi In order to repro in nushell, you need to have clickable_links enabled with $env.config.ls.clickable_links = true in the repl or set in the config.nu file. This enables OSC8 hyperlinks https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda in our ls output.

Another way to repro this is with printf '\e]8;;http://example.com\e\\example link\e]8;;\e\\\n' on macos/linux systems with the printf command. And then you can also see the results with rg like this:

I think rg may be working fine because the text actually contains two copies of "example", as in my repro but it could be unexpected by some folks. I'm not personally convinced a change is needed. In nushell, one could just strip the ansi escapes like this:

❯ printf '\e]8;;http://example.com\e\\example link\e]8;;\e\\\n' | ansi strip | rg example
example link