Improve `file://` hyperlinks support - local/remote hostname

[ltrzesniewski]

Description of the new feature/enhancement

Currently, Windows Terminal supports the following file:// URI patterns:

• file:///C:/SomeDir/SomeFile.txt
• file://localhost/C:/SomeDir/SomeFile.txt

The following patterns are rejected with a "This link type is currently not supported" message:

• file://wsl$/Ubuntu/SomeDir/SomeFile.txt
• file://remote_host/SomeDir/SomeFile.txt
• file://local_hostname/SomeDir/SomeFile.txt

Please add support for these cases. Note that the hyperlinks (OSC 8) spec requests for the hostname to be present in file URIs.

Proposed technical implementation details

The following justification is provided in the code:

https://github.com/microsoft/terminal/blob/54dc2c4432857919a6a87682a09bca06608155ed/src/cascadia/TerminalApp/TerminalPage.cpp#L2304-L2309

After testing with ShellExecuteEx (more precisely with Process.Start with UseShellExecute in .NET), I noticed the following:

• Remote hostnames (including wsl$) are supported just fine by the shell
• The local hostname results in the following error: "The system cannot find the file specified"

Therefore, I think the Windows Terminal should:

• Substitute the hostname in the URI with localhost if it happens to match the local hostname
• Maybe also support the FQDN?
• Try to open URIs with a remote hostname as-is

---

This relates to #7699 and #5001.

See also the discussion in https://github.com/BurntSushi/ripgrep/issues/665 for the problems this feature would solve.

Another example of a really useful usage this would enable would be oh-my-posh WSL links:

[ltrzesniewski]

As a bonus point, if Windows Terminal could also strip the fragment #xxx and query ?xxx parts of a file:// URI, that would be helpful for interoperability.

The Windows shell cannot handle those, but other terminals may use them for opening a text file at a given line for instance (e.g. kitty will interpret a #42 fragment as a line number). It would be nice if those links could work in WT as well, although with more limited functionality.

See the drama in https://github.com/BurntSushi/ripgrep/pull/2322 if you want more context.

[zadjii]

I also have thoughts on the matter as it relates to the pattern matching spec in progress (for after paternity leave)

[ShayBox]

This may be unrelated, I'm not sure

Web browsers, other programs, and terminals already allow for custom protocols registered by applications, for example: mailto:// skype:// curseforge:// vrcx:// etc

Why not expand Windows Terminal to support them? Probably with a trust prompt, similar to VSCodes workspace trust or Discords link trust.

[j4james]

@ShayBox Support for additional protocols was tracked in #7562, and was addressed by PR #14993, although that update hasn't been released yet.

[ltrzesniewski]

What happened to the monthly releases? 😢

[zadjii-msft]

@ltrzesniewski Monthly releases are a little easier when we're not entirely rewriting the process model of the Terminal (#5000) or entirely re-rewriting the rendering stack (#14959). Those two changes in particular took quite a bit longer to validate.

[ltrzesniewski]

@zadjii-msft That explains a lot of things, thanks for pointing it out! 🙂

[DHowett]

I didn't intend to let this one marinate for so long. After reading it initially, I let it grow into this huge and concerning feature request... but it really isn't that.

This is in line with the work we need to do to polish up hyperlinks in #8849. I'll keep it separate for now, but it's along the path we'll need to take to differentiate what we (1) detect and (2) launch and make those configurable.

[Diti]

The hyperlinks produced by eza (with eza --hyperlink /var/tmp for instance) in WSL also don’t work. Windows Terminal doesn’t seem to be aware it is in a WSL session and won’t transform the links to something like file://wsl$/WLinux/var/tmp. So clicking on the “regular” links have no effects.