Commands sent to terminal gets swallowed by previous command

[DonJayamanne]

• VSCode Version:Version 1.31.0-insider (1.31.0-insider)
• OS Version:Mac

Steps to Reproduce:

• Install latest version of Python Extension
• Install python
• Brew install pipenv
• Open a folder in VSC
• Add a python file with a simple print("Hello") statement
• Open the terminal in VSC and type the command pipenv shell
  • This will create a virtual environment for the current folder
• Open another terminal and notice how the Python extension will automatically add pipenv shell, causing the previously created environment to get activated in this new terminal.
• Reload VSC
  • The above pipenv environment will now be automatically selected
  • If not, please use the command Select Python Interpreter
  • From the list, of interpreters select the interpreter with the name same as the folder name you are in.
• Run python file in terminal
  • Open python file , right click and use the menu option Run Python file in terminal
  • The terminal will now open automatically
  • Python Extension will send the text pipenv shell to activate the environment in the terminal
  • The python extension will send the text <python interpreter> <file name> to the terminal
  • Unfortunately there's a race condition here, pipenv shell has not yet completed, and the commands sent later get swallowed up
• End result, file doesn't run in terminal

Causes:

• There's no way to determine when terminal has completed processing previously sent commands.
• VSC is sending messages to the terminal, when its busy

Solutions:

• Python extension adds a delay between the two commands being sent to the terminal (this is what we do today). However pipenv shell takes longer than other activation routines, hence we need a much longer delay (i.e. a bigger magic number), a work around.
• Or, VSC provides some api to let us know the terminal is ready to accept input.

Related to #67692

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Debugger commands sent to terminal get swallowed by previous terminal command (#67692)

[Tyriar]

I think this sort of thing normally happens because the command you ran consumed the input and didn't do anything with it. It doesn't happen for all commands only a subset, for example when developing VS Code you can run yarn<enter>yarn watch and the yarn watch will execute. This is acting as designed in my eyes and we can't really provide a generic API that knows when something has finished running afaict.

There's is a proposed API which lets you listen to the stream coming into the terminal which would allow you to determine when your command has run by matching some expected output:

https://github.com/Microsoft/vscode/blob/1bcf2c77ca766f23b9227ce5d18da8b10c53c803/src/vs/vscode.proposed.d.ts#L892-L897

Disposing the listener after you're done with the init check is a good idea. Would this work?

[DonJayamanne]

Great thanks, however we still have a problem with the debugger when using the terminal:

• We tell VS Code to launch the debugger in a terminal
• VS Code launcher a terminal to send the commands for debugging.
• We detect a terminal being opened and send a command to the terminal
• VS Code now sends the debugger commands to the terminal

Again, there's a race, VSC is sending text when the previous command sent by the extension has not completed.

There are a couple of solutions:

• VSC accepts some pre-initialization commands (such as initialize environment, this way the extension doesn't have to intercept the creation of the environment)
• Extension will have to first create a terminal, send the command and tell VSC to use this terminal instead of creating a new terminal
• Extension doesn't use debugger protocol to launch terminals, we do that our selves, (feels like we're re-inventing the wheel here, e.g. building commands, etc..)

Any other suggestions?

[Tyriar]

• VSC accepts some pre-initialization commands

This sounds promising, I'm not too familiar with how the debugger uses the terminal though.

[jamesstidard]

I believe I'm also seeing the same thing here. I've seen it for running debug configurations that try and use the integrated terminal and for installing linting packages from VCS popup prompts.

Using an external terminal seems to get around the issue for me currently for debugging.

Here's a youtube video where both the mypy linter install gets swallowed and the debugger.

[favna]

I also notice this but with a slightly different setup. First of all here is a video on streamable showing what happens

Now as for my setup:

• yarn init to create a new NodeJS project
• touch app.js create a simple app
• Just add something super basic like console.log('bugs galore?') to app.js
• Add a start script to your package.json
• Run yarn start

This however only happens to me when my terminal is set to Git Bash and only happens on Windows. Git Bash itself however works perfectly fine normally. Further things to note:

• Git For Windows v2.21.0 [install config: imgur album, I've also tried configuring differently)
• VSCode version 1.33.0 (stable) (System Setup, though happens on User Setup as well)
• Since I use yarn in the video, my yarn version is 1.15.2, Node version 11.13.0 and npm version 6.9.0.
• The issue does not happen in regular Git Bash terminal or the Hyper terminal which I also have use Git Bash
• The issue only seems to occur with yarn. Running npm start or node app.js does work.
  • While not as bad, running ng serve in my angular app does not clear the terminal as seen but the terminal does jump showing some commands from before I did a clear just before. So it's not entirely exclusive to yarn
  • It also seems to only happen when using the version installed with the ".msi" installer from their site, not when using one installed through npm i -g yarn

My VSCode settings concerning terminal are as follows (full config on gist here):

//...
    "terminal.integrated.shell.windows": "C:\\Program Files\\Git\\bin\\bash.exe",
    "terminal.integrated.env.windows": {"TERM": "cygwin"},
    "terminal.integrated.shellArgs.windows": ["--login"],
    "terminal.integrated.enableBell": true,
//...

[DonJayamanne]

@Tyriar I can see the label needs more info is still here. Are you still waiting on some information from my end?

[DonJayamanne]

@favna not sure how your issue is related to this.