"&" before running scripts when terminal set to powershell at user level and cmd at workspace level

[nironimous]

Environment data

• VS Code version: 1.44.1
• Extension version (available under the Extensions sidebar): 2020.3.71659
• OS and version: Windows 10 Pro
• Python version (& distribution if applicable, e.g. Anaconda): N/A
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): N/A

Expected behaviour

"Run Python file in Terminal" should trigger a command such as:
>C:/tools/miniconda3/envs/test/python.exe c:/_repos/test1/test.py

Actual behaviour

The powershell version of the run command with the leading "&" is used :

>& C:/tools/miniconda3/envs/test/python.exe c:/_repos/test1/test.py
& était inattendu

which would translate into "& was unexpected"

I face the same issue whatever the Python interpreter I use. Be it a conda one or not.

Steps to reproduce:

1. Create a simple python project
2. Set terminal.integrated.shell.windows to powershell at the user level.
   "terminal.integrated.shell.windows": "C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
3. Override the setting at the workspace level with cmd.exe.
   "terminal.integrated.shell.windows": "${env:SystemRoot}\system32\cmd.exe"

Run the script in Terminal => an & is front of the run command.

Misc

Tried older versions of the extension. Problem seems to have been introduced in 2020.2.62710.

It seems a similar issue was fixed in the past : #5913 , #5916

[karrtikr]

Thanks for reporting. Looks like we only read terminal.integrated.shell.windows from User settings, which is why we're detecting the shell as powershell instead of cmd and sending the wrong command to run file.
https://github.com/Microsoft/vscode-python/blob/7c81cfcd06cdbfd91224489864ac3c9ae2c16d59/src/client/common/terminal/shellDetectors/settingsShellDetector.ts#L31

[DonJayamanne]

terminal.integrated.shell.windows from User

Looks like VSC now allows setting this in workspace. previously this could only be set at a user level, hence the reason to check if it was user level.
FYI - I don't think this is a regression, i.e. it didn't work in a previous version of the extension did it?
Or did we actually break something?

[karrtikr]

Yes that's what I was thinking...

Problem seems to have been introduced in 2020.2.62710.

I marked it as regression due to this but you're right, doesn't seem like one.