rmyorston
need `/bin/sh` for certain scenarios, such running neovim for Windows under busybox.
Context:
busybox-win32 is my default shell on Windows 10.
Repro:
- Run neovim for windows under busybox for windows
- Run
:checkhealth
Result:
provider: health#provider#check
========================================================================
- ERROR: Failed to run healthcheck for "provider" plugin. Exception:
function health#check[20]..health#provider#check[5]..<SNR>116_check_node[20]..script C:\Program Files\Neovim\share\nvim\runtime\autoload\provider\node.vim[160]..function provider#node#Detect, line 16
Vim(let):E903: Process failed to start: no such file or directory: "/bin/sh"
It'd be nice to have /bin/sh path to get this work.
Error E903 is issued by the function channel_job_start() in src/nvim/channel.c. In this case it's trying to spawn a process with argv[0] set to /bin/sh. On Windows this isn't an absolute path: it refers to the file /bin/sh on the current drive. Such a file won't exist in a default Windows installation.
I'm not sure there's anything busybox-w32 should do about this.
(When busybox-w32 is asked to execute /bin/sh and the file doesn't exist it uses the built in shell applet instead. But in this case it's neovim that's trying to run /bin/sh.)
Can it override the file request to /bin/sh at exec level, just like how it is overridden at shell level?
The special treatment of a non-existent /bin/sh in busybox-w32 applies both in the shell and at exec level. But in this case the problem isn't in busybox-w32, it's in neovim.
A partial workaround is to make C:\bin\sh.exe a link to busybox-w32 (or a copy of it). That only works if your current drive is C:, though.
I see.
It's not a blocking issue. I will use neovim under cmd.exe as a workaround for now. Thanks!
If running from cmd.exe, neovim no longer assumes itself running under a POSIX environment and thus no longer seek for /bin/sh.
It's probably looking at some env var, so you can probably modify the var when launching neovim, e.g. using an alias.
Another option is to report this issue to neovim, because ultimately it is a neovim issue. I'm sure it should be fairly easy to fix.
@tigerinus: If it is executed from busybox ash inside cmd.exe can it properly detect it?
@tigerinus: If it is executed from busybox ash inside cmd.exe can it properly detect it?
It's the same issue. Something in busybox is making neovim-w32 thinking it's running under Linux like environment.