Repository navigation
${workspaceFolder} & . not being resolved in settings in some cases #11671
Description
Resolving ${workspaceFolder}
Having
"python.testing.unittestArgs": [
"-p",
"*test.py",
"-s",
"${workspaceFolder}/src",
]
instead of
"python.testing.unittestArgs": [
"-p",
"*test.py",
"-s",
"./src",
]
doesn't work.
Resolving .
This problem arises when using forward slashes in path.
"python.pythonPath": "./.venv/Scripts/python.exe" doesn't work but "python.pythonPath": ".\\.venv\\Scripts\\python.exe" does.
"python.testing.unittestArgs": [
"-p",
"*test.py",
"-s",
"./src",
],
"python.testing.cwd": "./test"
doesn't search for tests in ./test/src directory
Activity
martingbrown commentedon May 7, 2020
karrtikr commentedon May 7, 2020
[-]`${workspaceFolder}` & `.` not being resolved in testing settings[/-][+]`${workspaceFolder}` & `.` not being resolved in settings in some cases[/+]karrtikr commentedon Jul 30, 2020
For this particular case, we use
child_process.execwhich uses cmd shells to run./.venv/Scripts/python.exewhich fails, hence we're not able to resolve relative paths with forward slashes. However using full path with forward slashes work. Two possible solutions,child_process.spawnto run commands which return the result, which apparently doesn't use shell (?) cc Pavel Minaev (@int19h)vscode-python/src/client/common/configSettings.ts
Lines 641 to 654 in 620b614
We can change this line
to
int19h commentedon Jul 30, 2020
The real problem here is command line escaping, or lack thereof. Briefly, in cmd.exe, for historical reasons, the following is valid:
and is the same as:
There are many convoluted rules there that affect this behavior, and it's not really worthwhile trying to figure them all out. We should just avoid APIs like
exec()that take command line argument as a single string - those should do appropriate quoting.So, basically, always either
execFile()orspawn()(withshell: trueif needed - it defaults to false for both). Butexec()should be an extremely rare case - I doubt we have any scenarios where it's necessary. Any scenario that does justify it, also justifies a lengthy code comment explaining why it's needed :)And
shell: trueshould only be set if needed, because it's expensive to spawn shells, and they introduce more moving bits that can potentially fail. Like, in this case, it would be needed because we're running a batch script on Windows (but perhaps we can avoid that?).eleanorjboyd commentedon Dec 6, 2023
Tried this and it is working for me on the rewrite, please reopen if this is not the case and anyone thinks the problem still exists.
Thanks