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:

terminal/src/cascadia/TerminalApp/TerminalPage.cpp

Lines 2304 to 2309 in 54dc2c4

	// TODO: by the OSC 8 spec, if a hostname (other than localhost) is provided, we _should_ be
	// comparing that value against what is returned by GetComputerNameExW and making sure they match.
	// However, ShellExecute does not seem to be happy with file URIs of the form
	// file://{hostname}/path/to/file.ext
	// and so while we could do the hostname matching, we do not know how to actually open the URI
	// if its given in that form. So for now we ignore all hostnames other than localhost

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 BurntSushi/ripgrep#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 BurntSushi/ripgrep#2322 if you want more context.

[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.