Closed gopeter closed 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
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.
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:
TERM="linux"
seemed to work fine for meTERM="dumb"
also worked but it did cause my fancy prompt (Starship) to output a warning:
[4] pry(main)> `TERM="dumb" /bin/zsh -lic 'rbenv exec ruby -rjson -e "puts JSON.dump(ENV.to_h)"'`
[ERROR] - (starship::print): Under a 'dumb' terminal (TERM=dumb).
=> "{\"BUNDLER_ORIG_PATH\":...}\n"
The warning was printed to stderr though so it did not actually impact the return value and should still work.
@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.
I‘m using the default Mac Terminal app (and sometimes Warp) with ZSH (and oh-my-zsh), but not iTerm 2
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?
For sure:
$ ruby -e "p \`/bin/zsh -lic 'whoami'\`"
"peter_oesteritz\n"
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)\"'\`"
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
?
Oh, clever! Just updated and I no longer get the error.
It's working fine for me also 👍
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
@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?
@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.
I'm using VSCode Ruby LSP v.0.0.13,
ruby-lsp
0.3.8 andrbenv
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):Update 2
This doesn't happen with plugin version 0.0.12