You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, I've run into a strange issue on Windows where which does not find a binary with no extension.
I've been using the Helix editor which uses this crate to find language server and formatter binaries amongst other things. I compiled the Erlang language server from source and that resulted in a binary without the .exe extension. Using which in either Git Bash, Cmd or Powershell 7 correctly shows the path on my machine, which is /e/Projects/erlang_ls_bin/bin/erlang_ls and running erlang_ls correctly starts the server.
However, Helix cannot see it. I made a minimal example to test it like this:
fnmain(){let bin = "erlang_ls".to_string();match which::which(&bin){Ok(path) => {println!("Found path {:#?}", path.display().to_string());}Err(_) => {println!("Could not find binary in path");}}}
Which prints "Could not find binary in path". Is this expected behavior? I saw a couple of pull requests merged which make an extension optional as they will iterate through the possible ones automatically but I'm not entirely sure if I was correct since I don't use Rust.
Using which 4.3.0 on Windows 11 22621.819
Thanks in advance!
The text was updated successfully, but these errors were encountered:
I saw a couple of pull requests merged which make an extension optional
That PR allowed alternative extensions, but didn't account for no extension.
I honestly had no idea people wanted to execute files without an extension on Windows, but looking into it I can see quite a few requests to do exactly that online. This crate generally prefers to find files that we can reasonably infer are executable. Determining what is and isn't executable on Windows has been non-trivial. My only qualm with implementing this as requested is that it might result in which-rs occasionally returning ELF files which are stored on a Windows system. Like ideally an ELF file shouldn't be on a Windows machine, but I've seen it happen.
FWIW you can just rename the erlang server binary to have an exe extension in the meantime.
Hello, I've run into a strange issue on Windows where which does not find a binary with no extension.
I've been using the Helix editor which uses this crate to find language server and formatter binaries amongst other things. I compiled the Erlang language server from source and that resulted in a binary without the
.exe
extension. Usingwhich
in either Git Bash, Cmd or Powershell 7 correctly shows the path on my machine, which is/e/Projects/erlang_ls_bin/bin/erlang_ls
and runningerlang_ls
correctly starts the server.However, Helix cannot see it. I made a minimal example to test it like this:
Which prints "Could not find binary in path". Is this expected behavior? I saw a couple of pull requests merged which make an extension optional as they will iterate through the possible ones automatically but I'm not entirely sure if I was correct since I don't use Rust.
Using which 4.3.0 on Windows 11 22621.819
Thanks in advance!
The text was updated successfully, but these errors were encountered: