Shopify / ruby-lsp

An opinionated language server for Ruby
https://shopify.github.io/ruby-lsp/
MIT License
1.53k stars 146 forks source link

Failed to activate rbenv environment: Unexpected token F in JSON at position 0 #1509

Closed gopeter closed 1 year ago

gopeter commented 1 year ago

I'm using VSCode Ruby LSP v.0.0.13, ruby-lsp 0.3.8 and rbenv and get this error message when I open VSCode:

Failed to activate rbenv environment: Unexpected token F in JSON at position 0

I have no clue how I can help to debug this. I tried to get some information in VSCode's developer console, but didn't found anything helpful.

Update

I've also checked if rbenv is available in VSCode's terminal (which is the case):

rbenv -v
rbenv 1.2.0

Update 2

This doesn't happen with plugin version 0.0.12

olivier-thatch commented 1 year ago

I'm running into a similar issue, except that the error message indicates that JSON parsing fails on a whitespace character (or possibly no character?):

Failed to activate rbenv environment: Unexpected token  in JSON at position 0

I've tried manually running the same command that the extension itself runs:

$ /bin/zsh -lic 'rbenv exec ruby -rjson -e "puts JSON.dump(ENV.to_h)"'
{"RBENV_VERSION":"3.2.0",...}

I suspect Shopify/vscode-ruby-lsp#349 broke something as I don't think this was happening with 0.0.12.

EDIT: Ah yep, looks like the -i flag passed to the shell causes the string that's returned to include the shell's prompt:

[1] pry(main)> `/bin/zsh -lic 'rbenv exec ruby -rjson -e "puts JSON.dump(ENV.to_h)"'`
=> "\e]1337;RemoteHost=olivier@thatch-olivier.local\a\e]1337;CurrentDir=/Users/olivier/thatch-health/thatch\a\e]1337;ShellIntegrationVersion=13;shell=zsh\a{\"BUNDLER_ORIG_PATH\",...}\n"

[2] pry(main)> `/bin/zsh -lc 'rbenv exec ruby -rjson -e "puts JSON.dump(ENV.to_h)"'`
=> "{\"BUNDLER_ORIG_PATH\":...}\n"

cc @vinistock @andyw8

vinistock commented 1 year ago

Thanks for the bug report. Could you please confirm if these alternatives print the JSON without including the prompt?

# Either this
`/bin/zsh -lic  --no-promptcr 'rbenv exec ruby -rjson -e "puts JSON.dump(ENV.to_h)"'`

# Or this
`PS1="" /bin/zsh -lic 'rbenv exec ruby -rjson -e "puts JSON.dump(ENV.to_h)"'`

Trying to understand if there's a way in which we can get rid of the prompt while still using the interactive shell to activate the environment.

olivier-thatch commented 1 year ago

Neither worked, but I did figure out something: the culprit is not actually the prompt, it's the iTerm2 shell integration.

The script being sourced in my .zshrc causing the issue is this one: https://github.com/manicminer/dotfiles/blob/main/iterm2_shell_integration.zsh

So you could fix the issue by pretending the shell integration script has already run by setting ITERM_SHELL_INTEGRATION_INSTALLED to any value:

# This works
`ITERM_SHELL_INTEGRATION_INSTALLED="Yes" /bin/zsh -lic 'rbenv exec ruby -rjson -e "puts JSON.dump(ENV.to_h)"'`

Or alternatively, setting TERM to either dumb or linux, though these may have other side-effects. I gave both of them a try:

The warning was printed to stderr though so it did not actually impact the return value and should still work.

vinistock commented 1 year ago

@gopeter are you using iTerm2 as well? Could you please confirm if these approaches work for you as well?

I'm wondering if this is going to be an iTerm2 + zsh specific issue or if it could affect other combinations too. Ideally, we'd find a solution that is generic enough to prevent issues from happening in any terminal.

gopeter commented 1 year ago

I‘m using the default Mac Terminal app (and sometimes Warp) with ZSH (and oh-my-zsh), but not iTerm 2

olivier-thatch commented 1 year ago

In my case the escape sequence used by the iTerm2 shell integration (\e]1337;) is what causes JSON parsing to fail with Unexpected token � in JSON at position 0.

@gopeter reported a different character: Unexpected token F in JSON at position 0 so it's likely something else being sourced from their .zshrc that's causing a string starting with F to be preprended to the expected JSON hash.

@gopeter Can you try executing this command:

$ ruby -e "p \`/bin/zsh -lic 'whoami'\`"

and report the exact output here? Seeing the full string should help pinpoint what's causing the issue in your environment.

Also, are you using a specific zsh theme and/or custom prompt?

gopeter commented 1 year ago

For sure:

$ ruby -e "p \`/bin/zsh -lic 'whoami'\`"
"peter_oesteritz\n"
olivier-thatch commented 1 year ago

Weird, that doesn't seem to include any extra characters 🤔

@gopeter Can you try running this command from the same directory that you're opening as the VSCode project where you're seeing the Ruby LSP error (to make sure it's using the same .ruby-version and environment):

$ rbenv exec ruby -e "p \`#{ENV['SHELL']} -lic 'rbenv exec ruby -rjson -e \"puts JSON.dump(ENV.to_h)\"'\`"
vinistock commented 1 year ago

We went with a different approach that will be more generic and not as tied to which terminal/shell combination people are using. Could you folks try v0.1.0?

olivier-thatch commented 1 year ago

Oh, clever! Just updated and I no longer get the error.

gopeter commented 1 year ago

It's working fine for me also 👍

dpetruha commented 7 months ago

I think this problem is back again for, at least, v0.6.10 (pre-release). I have zsh and some plugins installed with OhMyZsh. Getting the following error:

Failed to activate Ruby environment: Unexpected token I in JSON at position 0
image

@vinistock , maybe you can help here.

P.s. I have also noticed that in v0.6.10 Ruby Lsp: Ruby Version Manager configuration property has been removed. And now, it seems, the plugin just tries to use ruby executable through Ruby Lsp: Ruby Executable Path. Not sure if this is somehow related to the issue.

If problem in zsh, can I somehow tell Ruby LSP to use different shell to run what it needs?

vinistock commented 7 months ago

@dpetruha can you please open a separate bug report? While the error is similar, the root cause doesn't seem related. With the preview version of the extension, we no longer rely on the shell for anything, so it shouldn't be related to zsh.