starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Improve file:// hyperlinks support - local/remote hostname #18584

New Issue
Open
opened 2026-01-31 06:18:26 +00:00 by claunia · 9 comments
claunia commented 2026-01-31 06:18:26 +00:00
Owner
Copy Link

Originally created by @ltrzesniewski on GitHub (Oct 2, 2022).

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:

54dc2c4432/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:

image

Originally created by @ltrzesniewski on GitHub (Oct 2, 2022). # 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](https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda) 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: ![image](https://user-images.githubusercontent.com/7913492/193453435-40869283-4aa0-4a97-bcc2-a2828ef36e74.png)
claunia added the Issue-FeaturePriority-3Product-TerminalArea-UserInterface labels 2026-01-31 06:18:27 +00:00
claunia commented 2026-01-31 06:18:27 +00:00
Author
Owner
Copy Link

@ltrzesniewski commented on GitHub (Oct 3, 2022):

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.

@ltrzesniewski commented on GitHub (Oct 3, 2022): 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.
claunia commented 2026-01-31 06:18:28 +00:00
Author
Owner
Copy Link

@zadjii commented on GitHub (Oct 5, 2022):

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

@zadjii commented on GitHub (Oct 5, 2022): I also have thoughts on the matter as it relates to the pattern matching spec in progress (for after paternity leave)
claunia commented 2026-01-31 06:18:28 +00:00
Author
Owner
Copy Link

@ShayBox commented on GitHub (May 7, 2023):

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.

@ShayBox commented on GitHub (May 7, 2023): 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.
claunia commented 2026-01-31 06:18:28 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (May 7, 2023):

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

@j4james commented on GitHub (May 7, 2023): @ShayBox Support for additional protocols was tracked in #7562, and was addressed by PR #14993, although that update hasn't been released yet.
claunia commented 2026-01-31 06:18:28 +00:00
Author
Owner
Copy Link

@ltrzesniewski commented on GitHub (May 7, 2023):

What happened to the monthly releases? 😢

@ltrzesniewski commented on GitHub (May 7, 2023): What happened to the monthly releases? 😢
claunia commented 2026-01-31 06:18:28 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 8, 2023):

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

@zadjii-msft commented on GitHub (May 8, 2023): @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.
claunia commented 2026-01-31 06:18:29 +00:00
Author
Owner
Copy Link

@ltrzesniewski commented on GitHub (May 8, 2023):

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

@ltrzesniewski commented on GitHub (May 8, 2023): @zadjii-msft That explains a lot of things, thanks for pointing it out! 🙂
claunia commented 2026-01-31 06:18:29 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 19, 2023):

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.

@DHowett commented on GitHub (Jul 19, 2023): 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.
claunia commented 2026-01-31 06:18:29 +00:00
Author
Owner
Copy Link

@Diti commented on GitHub (Sep 7, 2024):

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.

@Diti commented on GitHub (Sep 7, 2024): The hyperlinks produced by [eza](/eza-community/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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-UserInterface Issue-Feature Priority-3 Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#18584
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?