Extension is using a different shell then vcode

[Goltergaul]

Operating System

mac os sonoma 14.3 (23D56)

Ruby version

3.3.0

Project has a bundle

• Has bundle

Ruby version manager being used

rbenv

Description

the lsp server can't start and gives this error:

Failed to activate rbenv environment: Command failed: /bin/sh -i -c 'rbenv exec 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) }))"' sh: no job control in this shell sh: rbenv: command not found

the issue is that the sh shell is not configured. in vcscode i use zsh as the default shell for the terminal

[aleesilva]

I have same problem.
I've already tried overwriting the configuration of vscode integrated terminal but it still does the wrong thing.

[vinistock]

Thank you for the bug report!

We received other reports related to selecting /bin/sh and it seems like it could be related to disk access permissions. You don't need to give full disk access to VS Code (I don't do it and the LSP works), but it seems like there's some permission that when denied makes it select the incorrect shell.

There are two options here:

• If you can help us figure out exactly what permission you denied to VS Code, that would be incredibly helpful to understand what conditions lead to this outcome
• Because shell related issues have caused a lot of headache, we're experimenting with a new Ruby activation mechanism. This can be used in the prerelease version of the extension. If you're willing to give the prerelease a try, we're looking for feedback!

[aleesilva]

thanks @vinistock I'll try to find out what's going on with the permissions

[Goltergaul]

@vinistock thank you, giving full access worked. I'm not aware I denied any access in the past but not sure, maybe there was something. Only thing that comes to my mind is that question from vs code when it asks if you trust the other stuff in the parent project folder or something. there i sometimes klicked no

[vinistock]

Okay, so that's a good indication that the whole /bin/sh problem is indeed related to permissions. If someone can figure out exactly which one was denied, please let us know. We can then make the extension check for that permission and present a nice dialog message instead of simply failing.

[Goltergaul]

I need to correct myself. It worked after I did this but now it does not work again. I did not change anything though

[vinistock]

I believe this issue is already fixed by #1811, which decoupled the activation from the shell.

Please let us know if this isn't the case.