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
Using pwsh (variant 7/new) to try and initialize a new connection via handing my_username@home_ip_addr - p 22
results in 2 failings to identify correct OS and handle command exec via the right shell.
Determining OS on remote machine
Shell command passed through attempts to use uname -s -m despite being on Windows, which the plugin will know by the time it's running this I would assume -as it makes the initial connection calls via pwsh.
Do note: This also doesn't respect any of the vim.g.shell* commands at all, breaking the shellcmdflag that handles pwsh.exe's encoding arg given in the options.lua file.
I was able to test a workaround via manually editing the repo's code in:
Line 159 - Adding the line self._remote_os = "Windows"
partially resolves the issue, allowing me through to the following step of "Checking if Neovim is installed system-wide on remote".
This then attempts to call nvim --version || true which is incorrect syntax if working with pwsh.exe.
I have not had a look at some sort of hacky work-around to point you in the right direction for this one unfortunately lol
My dotfiles are publicly available if you'd like to see more details, can link directly if helps.
Can test with the repo below later
Use the repro.lua to
reproduce the issue. This provides me with a better chance to reproduce the issue.
This also provides a sanity check of if the issue is with the plugin or some other part of your configuration.
Incase you cannot and still feel something is off with the plugin, do report. I won't bite!
Steps to reproduce the behavior:
Run nvim -u <repro.lua>
Add your steps...
Expected behavior
Correct handling of OS to commandline translation, with a preference to either expose the OS entries in the plugin via a config variable, and documenting where you get it from, or what it defaults to.
Maintaining shell specific vim.g.shell* options as a part of this process if possible.
Screenshot/Screencast(s)
N/A
System information
Your local OS: Windows 10 (Corporate Special)
Local Neovim version: v0.10.2
Remote host OS (if applicable): Windows 11
Remote Neovim version (if applicable): AA.
Additional context
I don't use SSH often so this might be an ID10T error (User error lol), but the behaviour should be configurable and follow existing settings already defined in a much earlier stage of the lazy.nvim load order(s) anyway.
I can take a look at this and see if I can find a hacky workaround and post here if I find one, with the aim to perhaps lower the fix time etc.
The text was updated successfully, but these errors were encountered:
Describe the bug
Using pwsh (variant 7/new) to try and initialize a new connection via handing my_username@home_ip_addr - p 22
results in 2 failings to identify correct OS and handle command exec via the right shell.
Shell command passed through attempts to use
uname -s -m
despite being on Windows, which the plugin will know by the time it's running this I would assume -as it makes the initial connection calls via pwsh.Do note: This also doesn't respect any of the
vim.g.shell*
commands at all, breaking the shellcmdflag that handles pwsh.exe's encoding arg given in theoptions.lua
file.I was able to test a workaround via manually editing the repo's code in:
nvim-data/lazy/remote-nvim.nvim/lua/remote-nvim/providers/provider.lua:159
Line 159 - Adding the line
self._remote_os = "Windows"
partially resolves the issue, allowing me through to the following step of "Checking if Neovim is installed system-wide on remote".
This then attempts to call
nvim --version || true
which is incorrect syntax if working with pwsh.exe.I have not had a look at some sort of hacky work-around to point you in the right direction for this one unfortunately lol
To reproduce
In a min. config, options.lua -
My dotfiles are publicly available if you'd like to see more details, can link directly if helps.
Can test with the repo below later
Use the repro.lua to
reproduce the issue. This provides me with a better chance to reproduce the issue.
This also provides a sanity check of if the issue is with the plugin or some other part of your configuration.
Incase you cannot and still feel something is off with the plugin, do report. I won't bite!
Steps to reproduce the behavior:
nvim -u <repro.lua>
Expected behavior
Correct handling of OS to commandline translation, with a preference to either expose the OS entries in the plugin via a config variable, and documenting where you get it from, or what it defaults to.
Maintaining shell specific vim.g.shell* options as a part of this process if possible.
Screenshot/Screencast(s)
N/A
System information
Additional context
I don't use SSH often so this might be an ID10T error (User error lol), but the behaviour should be configurable and follow existing settings already defined in a much earlier stage of the lazy.nvim load order(s) anyway.
I can take a look at this and see if I can find a hacky workaround and post here if I find one, with the aim to perhaps lower the fix time etc.
The text was updated successfully, but these errors were encountered: