fd [BUG] Hyperlinks fail on Windows when file path contains spaces

Checks

[x] I have read the troubleshooting section and still think this is a bug.

Describe the bug you encountered:

Setup (pwsh):

mkdir C:\test
pushd C:\test
New-Item hi.txt
New-Item 'hi there.txt'

Run:

C:\test
> fd -e txt--hyperlink=auto -d1

hi there.txt
hi.txt
# entries are underlined in Windows Terminal to indicate hyperlinks

# Observed hyperlinks from fd==10.2.0 on Windows
file://C:/test/hi%20there.txt  # FAILURE
file://C:/test/hi.txt  # SUCCESS

The file:// part is missing the third slash for local host. The issue affects filepaths with spaces (and maybe other escape chars; I haven't checked). Filepaths without spaces open fine, even with two slashes.

I'm not a Rust person but it looks like adding a slash '/' to the Windows host function in hyperlinks.rs would fix it for my use case, which is drive-based paths. No idea how UNC paths will behave (they're also broken right now, see below).

#[cfg(windows)]
const fn host() -> &'static str {
    "/"
}

Other notes:

if I run from a mapped network drive N:\test, I get the same results - 2 slashes - file://N:/test/hi%20there.txt
if I run from a bare UNC path on the network \\192.168.0.20\share\test, I'll get 4 slashes file:////192.168.0.20/share/test/hi%20there.txt, and Terminal declares the link as unsupported. I know UNC paths are not supported (https://github.com/microsoft/terminal/issues/19236 ) and I personally don't care about this use case at all. But the correct hyperlink would be 2 slashes file://192.168.0.20/share/test/hi%20there.txt

(Terminal Error Message)

This link type is currently not supported:
file:////192.168.0.20/share/test/hi%20there.txt

Describe what you expected to happen:

# Expected RFC 3986 URLs
file:///C:/test/hi%20there.txt 
file:///C:/test/hi.txt

What version of `fd` are you using?

10.2.0

Which operating system / distribution are you on?

- Windows 10 and 11
- pwsh 7.4 and 7.5
- Windows Terminal

Nov 21 '25 20:11 davidstadem

I'm not an expert on Windows, but I don't believe there is supposed to be a third slash there.

On Unix, there are three slashes because the root of the path is "/", but on Windows it is a drive letter.

I'm not sure what spaces would have to do with this though. Do you get three slashes for a path that doesn't have spaces?

EDIT: I also noticed that your output is using forward slashes instead of back slashes. Are you using a windows-gnu target build of fd? I'm not sure if your terminal would be able to handle a link that uses forward slashes instead of back slashes.

Nov 22 '25 09:11 tmccombs

Thanks for the reply @tmccombs -

a) it's a normal windows build (installed with WinGet). Windows does use forward slashes for file path hyperlinks (URIs). These examples from Wikipedia match my experience of how Windows file:// URIs work; I think it's based on RFC 3986. I verified that the "expected" URIs (e.g. file:///C:/test/hi%20there.txt) work by running them in the Windows Run (Win+R) command.

b) the reason the spaces have anything to do with it is because Windows and Windows apps have various workarounds that accommodate non-standard URIs - some (IE) use | instead of :, some will accept different numbers of slashes, and often / and \ are interchangeable for the file path.

[BUG] Hyperlinks fail on Windows when file path contains spaces

Checks

Describe the bug you encountered:

Describe what you expected to happen:

What version of fd are you using?

Which operating system / distribution are you on?

What version of `fd` are you using?