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

[Windows | shell] Incorrect command(s) being used for OS. #177

Open
MrDwarf7 opened this issue Oct 17, 2024 · 0 comments
Open

[Windows | shell] Incorrect command(s) being used for OS. #177

MrDwarf7 opened this issue Oct 17, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@MrDwarf7
Copy link

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.

  1. 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:

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 -

M.get_os = function()
	---@type OperatingSystemEnum
	local os_t = vim.loop.os_uname().sysname
	return assert(os_t, "Operating system not found in list")
end
vim.g.os = require("util.architecture").get_os()
if vim.g.os == "Windows_NT" then
	local powershell_opts = {
		shell = "pwsh",
		shellcmdflag = "-NoProfile -NoLogo -ExecutionPolicy RemoteSigned -Command [Console]::InputEncoding=[Console]::OutputEncoding=[System.Text.UTF8Encoding]::new();$PSDefaultParameterValues['Out-File:Encoding']='utf8';$PSStyle.OutputRendering = [System.Management.Automation.OutputRendering]::PlainText;",
		shellredir = '2>&1 | %%{ "$_" } | Out-File %s; exit $LastExitCode',
		shellpipe = '2>&1 | %%{ "$_" } | Tee-Object %s; exit $LastExitCode',
		shellquote = "",
		shellxquote = "",

		-- Original settings
		-- shell = "pwsh",
		-- shellcmdflag = "-NoLogo -NoProfile -ExecutionPolicy RemoteSigned -Command [Console]InputEncoding=[Console]::OutputEncoding=[System.Text.Encoding]::UTF8;",
		-- shellredir = "2>&1 | Out-File -Encoding UTF8 %s; exit $LastExitCode",
		-- shellpipe = "2>&1 | Out-File -Encoding UTF8 %s; exit $LastExitCode",
		-- shellquote = "",
		-- shellxquote = "",
	}
	for k, v in pairs(powershell_opts) do
		vim.o[k] = v
	end
end

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:

  1. Run nvim -u <repro.lua>
  2. 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.

@MrDwarf7 MrDwarf7 added the bug Something isn't working label Oct 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant