iTerm 2's shell integration causes the Installed tab to throw "Failed to decode Homebrew JSON output".
LoginShellBrewCommandRunner runs brew through -l -i -c 'exec ...' inside a pty for terminal parity, and BrewCommandService treats the whole pty transcript as the command's output. Problem is -i makes the shell fully load interactive rc files, and anything those print to stdout before the exec line runs ends up glued onto the front of brew's JSON.
In iTerm2's official shell integration script (~/.iterm2_shell_integration.fish), its guard only checks status --is-interactive and $TERM, not $TERM_PROGRAM, so it fires here too and prints its OSC 1337 handshake before anything else. So the "JSON" actually starts with escape codes instead of {.
To reproduce: set fish as your login shell, install iTerm2's shell integration for fish, open the app, go to Installed.
I added a guard so the iTerm2 shell integration script only loads when you're actually inside iTerm2, instead of loading any time an interactive shell starts.
The original line in ~/.config/fish/config.fish was:
test -e {$HOME}/.iterm2_shell_integration.fish ; and source {$HOME}/.iterm2_shell_integration.fish
It only checked that the file existed, not where it was running. Changed to:
test "$TERM_PROGRAM" = "iTerm.app" ; and test -e {$HOME}/.iterm2_shell_integration.fish ; and source {$HOME}/.iterm2_shell_integration.fish
This obviously fixes it on the iTerm side, but I figured I'd open an issue here since this app is directly affected by the standard behavior of a fairly common script.
iTerm 2's shell integration causes the Installed tab to throw "Failed to decode Homebrew JSON output".
LoginShellBrewCommandRunner runs brew through -l -i -c 'exec ...' inside a pty for terminal parity, and BrewCommandService treats the whole pty transcript as the command's output. Problem is -i makes the shell fully load interactive rc files, and anything those print to stdout before the exec line runs ends up glued onto the front of brew's JSON.
In iTerm2's official shell integration script (~/.iterm2_shell_integration.fish), its guard only checks status --is-interactive and $TERM, not $TERM_PROGRAM, so it fires here too and prints its OSC 1337 handshake before anything else. So the "JSON" actually starts with escape codes instead of {.
To reproduce: set fish as your login shell, install iTerm2's shell integration for fish, open the app, go to Installed.
I added a guard so the iTerm2 shell integration script only loads when you're actually inside iTerm2, instead of loading any time an interactive shell starts.
The original line in ~/.config/fish/config.fish was:
It only checked that the file existed, not where it was running. Changed to:
This obviously fixes it on the iTerm side, but I figured I'd open an issue here since this app is directly affected by the standard behavior of a fairly common script.