Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

findExecutable "\\" on windows is confusing #187

Open
hasufell opened this issue Aug 17, 2024 · 4 comments
Open

findExecutable "\\" on windows is confusing #187

hasufell opened this issue Aug 17, 2024 · 4 comments

Comments

@hasufell
Copy link
Member

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

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

@hasufell
Copy link
Member Author

hasufell commented Aug 17, 2024

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
Copy link
Member Author

Related: #180

@hasufell
Copy link
Member Author

hasufell commented Aug 17, 2024

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
Copy link
Contributor

Mistuke commented Sep 7, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants