Setup on Windows machines picks wrong terminal

[MrMcDaddy]

Operating System

Windows 11

Ruby version

3.2.2

Project has a bundle

• Has bundle

Ruby version manager being used

no manager

Description

The flow of things on a windows machine is pretty much as follows:

1. Install Ruby-LSP extension
2. See error message popping up that says "command 'ruby' unknown"
3. Configure "SHELL" system environment variable to point to default "Git for Windows" directory
4. Retry, get greeted by a message that "C:\Program" is not a command
5. Reinstall Git for Windows straight on C:
6. Retry and get greeted by this monstrosity:
   C:\Git\bin\bash.exe -ic 'ruby -rjson -e "STDERR.printf(%{RUBY_ENV_ACTIVATE%sRUBY_ENV_ACTIVATE}, JSON.dump({ env: ENV.to_h, ruby_version: RUBY_VERSION, yjit: defined?(RubyVM::YJIT) }))"' bash: cannot set terminal process group (-1): Inappropriate ioctl for device bash: no job control in this shell

The reason I'm not using any version manager is that whatever I'm trying to use, VS-Code tries to run the background task in CMD, which isn't really configured to be used for anything, so it fails to find the version managers or ruby itself.
The flow appears to be "CMD -> Bash -> Ruby".

I tried to change all VS Code Settings related to this, but had no luck whatsoever.

"terminal.external.windowsExec": "Git Bash",
"terminal.integrated.automationProfile.windows": {
    "path": "C:\\Git\\bin\\bash.exe"
},

I'm using Git Bash as my default terminal everywhere else on my computer, even as the default terminal within VS Code.

[nathanscottdaniels]

I am having a similar problem but on Linux with pwsh as my default shell. It looks like this extension tries to run

/usr/bin/pwsh -ic 'ruby -rjson -e "STDERR.printf(%{RUBY_ENV_ACTIVATE%sRUBY_ENV_ACTIVATE}, JSON.dump({ env: ENV.to_h, ruby_version: RUBY_VERSION, yjit: defined?(RubyVM::YJIT) }))

but pwsh doesn't have an -ic argument so it fails.

The extension should probably always use bash if that's what it's expecting

[vinistock]

Currently, we use the shell to activate the Ruby environment using the correct version and gem paths. We need to use the default shell because that's typically where users have their version manager configuration (things like sourcing chruby or rbenv). Otherwise, we would not be able to invoke the version manager to get the environment activated.

This coupling with the shell has proved brittle and too easily broken by different shells, configurations or plugins. I am exploring trying to fully decouple us from the shell, so that this class of problems can go away. However, it will take a little bit to get that done as it'll require ensuring that it works for all version managers we support.

[vinistock]

We made a preview release with a re-work of how Ruby activation works.

If you'd like to give that a try and provide feedback if it works for your setups, that would be helpful.

[MrMcDaddy]

It appears to work just fine now!
No errors are thrown, everything is displayed as active and so far, it does look like the features are working as expected.
That was super quick, thank you for this!

[vinistock]

I'm very happy to hear that! Ruby environment activation is not easy to get right, so I appreciate the patience and the feedback. Too many combinations of shells, version managers, operating systems, etc.

The new activation mechanism will remain as experimental (preview release) until we can iron out any bugs or edge cases we didn't foresee. Hopefully this will be a much smoother experience for everybody.

[github-actions]

This issue is being marked as stale because there was no activity in the last 2 months