`findExecutable "\\"` on windows is confusing

[hasufell]

ghci> findExecutable "\\"
Just "C:\\"

I'm not sure what's going on there, but that's certainly not an executable.

[hasufell]

Apparently that's how SearchPathW behaves. Trying further:

ghci> searchPath Nothing "\\lol" (Just ".exe")
Just "C:\\lol"
ghci> searchPath Nothing "C:\\lol" (Just ".exe")
Just "C:\\lol"
ghci> searchPath Nothing "\\\\" (Just ".exe")
Nothing

@Mistuke

[hasufell]

Related: #180

[hasufell]

Alright, it appears:

1. absolute paths are just returned as-is by SearchPathW
2. albeit we consider "\\" as relative in System.FilePath (it's meaning is "relative to the current processes device root"), the windows API seems to treat it as absolute (since it's "relative" to a device root and not a working dir)
3. "\\\\" is the start of a UNC path (shared drive here) and likely disables some parsing logic in the API, leading it to not be considered as absolute by the API
4. Another peculiarity is "C:foo", which means "relative to the current processes working dir on device C" and is considered relative, unlike "\\foo"

The filepath package disagrees with the windows API on what is an absolute filepath. So one way to fix this could be to return Nothing if:

• the filepath starts with one filepath separator, but not two or
• the filepath starts with a drive letter

[Mistuke]

Alright, it appears:

1. absolute paths are just returned as-is by SearchPathW
2. albeit we consider "\\" as relative in System.FilePath (it's meaning is "relative to the current processes device root"), the windows API seems to treat it as absolute (since it's "relative" to a device root and not a working dir)
3. "\\\\" is the start of a UNC path (shared drive here) and likely disables some parsing logic in the API, leading it to not be considered as absolute by the API
4. Another peculiarity is "C:foo", which means "relative to the current processes working dir on device C" and is considered relative, unlike "\\foo"

The filepath package disagrees with the windows API on what is an absolute filepath. So one way to fix this could be to return Nothing if:

• the filepath starts with one filepath separator, but not two or
• the filepath starts with a drive letter

Yeah that seems like the best solution. I think it makes sense to have a higher lever library like directory be consistent cross platforms