CODEWITHSUNDEEP
bashvisual-studio-codezshzshrcluxonis
flip
flip

Reputation: 235

Failure to launch - shells and incomplete commands - in VScode

I seem to be having an interesting problem on occasion when vscode tries to launch a shell, especially during debugging.

For example, I'm trying to debug a Python program that uses an Anaconda venv. Everything is set up correctly from the interpreter's POV and all that. Indeed, if I run the commands that vscode is trying to evaluate in the shell 'by hand' everything works, debuggery-wise.

But - the first time I try, I get a weird mess in the terminal window when I launch the program to debug.

Output from the terminal window is seen below -

source /Users/flip/opt/anaconda3/bin/activate
 ~/G/depthai> da3/bin/activate
zsh: no such file or directory: da3/bin/activate
 127  ~/G/depthai> nconda activate depthai
zsh: command not found: nconda

What seems to be happening is that vscode is trying to source /Users/flip/opt/anaconda3/bin/activate and a bunch of characters aren't making it to to the shell itself (the first part of the string, /Users/flip/opt/anacon to be specific)

Then, as you can see it's trying to run conda activate depthai and, this time, an n is being prepended to the command. Very weird, suspicious, and all that.

This seems to happen w/ bash and zsh on both macOS and on my Linux boxes. It feels like there's something weird / messy in whichever rc files are getting executed. I've been using a similar configuration of .profile and friends for literally decades and, at some point, maybe I added something that is doing naughty IO?

Any thoughts out there?

Upvotes: 1

Views: 313

Answers (1)

AlexJF
AlexJF

Reputation: 886

What ultimately solved it for me was overriding the shell used for automation tasks (like debugging) to the barebones /bin/sh which should load as fast as possible. You can do so by adding the following to your VSCode's settings.json:

  "terminal.integrated.automationProfile.linux": {
    "path": "/bin/sh"
  },
  "terminal.integrated.automationProfile.osx": {
    "path": "/bin/sh"
  }

If falling back to /bin/sh isn't an option for some reason, you can use the same mechanism to keep the same shell but override args/env variables allowing you to conditionally speed up initialization in your .zprofile/.zshrc scripts (e.g. skip loading of unnecessary plugins):

"terminal.integrated.automationProfile.osx": {
    "path": "/bin/zsh",
    "args": ["-l"],
    "env": {
      "FAST_INIT": "true"
    }
  },

Background

I was having a similar issue with the node debugger where the command injection done when launching the debug session would get intermittently truncated. This truncation invariably led to the debugger being stuck waiting for extra input due to an unterminated string.

alexandre.fonseca ~/myProject                                                            17:28:54
❯ esources/app/extensions/ms-vscode.js-debug/src/bootloader.js" --inspect-publish-uid=http' 'VSCODE_INSPECTOR_OPTIONS={"inspectorIpc":"/var/folders/yz/1ddh54557hj_lxdt_55x3q
mr0000gp/T/node-cdp.54381-bc269a2e-1.sock","deferredMode":false,"waitForDebugger":"","execPath":"/Users/alexandre.fonseca/.asdf/shims/node","onlyEntrypoint":false,"autoAttac
hMode":"always","fileCallback":"/var/folders/yz/1ddh54557hj_lxdt_55x3qmr0000gp/T/node-debug-callback-84b6ad0f17eec2d2"}' /Users/alexandre.fonseca/.asdf/shims/yarn test:unit 
/Users/alexandre.fonseca/myProject/process-response.unit.ts 
>

Disabling my fancy ZSH prompt plugins seemed to make the issue occur less frequently.

Stumbled upon https://github.com/microsoft/vscode/issues/38578#issuecomment-725558731 which suggests command injection is based purely on time and thus quite easy to race with complex shell initialization scripts.

Upvotes: 2

Related Questions