-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spaces in python interpreter path or program result in incorrectly quoted debugging commands with arguments #233
Comments
Same thing is happening to me, both with type python and debugpy |
Same issue here. My user folder (Windows 10) happens to contain spaces, which causes problems. It seems that the debugpy configuration with arguments is behaving differently than the "current file with no arguments" one. When running with default configuration in {
"name": "Python Debugger: Current File",
"type": "debugpy",
"request": "launch",
"program": "${file}",
"console": "integratedTerminal"
} The python executable and debugy launcher paths are wrapped in quotes, so it works. The following command is executed in PowerShell when running this configuration, and works: (note "User Name" with spaces) c:; cd 'c:\Path\Current\Directory'; & 'c:\Users\User Name\AppData\Local\Programs\Python\Python310\python.exe' 'c:\Users\User Name\.vscode\extensions\ms-python.debugpy-2024.4.0-win32-x-2024.4.0-win32-x64\bundled\libs\debugpy\adapter/../..\debugpy\launcher' '52298' '--' 'C:\Local\my-repo\my-script.py' However, the configuration with arguments results in the following command being called, which is results in the same problem as the original ticket: c:\Users\User Name\AppData\Local\Programs\Python\Python310\python.exe c:\Users\User Name\.vscode\extensions\ms-python.debugpy-2024.4.0-win32-x64\bundled\libs\debugpy\adapter/../..\debugpy\launcher 52061 -- C:\Local\my-repo\my-script.py -i "input.txt" Wrapping the |
Using launch.json, the problem only occurs in certain conditions (VSCode Version: 1.85.1 (Windows)): A. set args to a string
B. set args to a list of strings
The terminal says it is running
{
"version": "0.2.0",
"configurations": [
{
"name": "some_script some_file.txt",
"type": "debugpy",
"request": "launch",
"program": "some_script.py",
"console": "integratedTerminal",
"args": ["c:\\Users\\redacted\\Desktop\\some_file.txt"]
}
]
} |
Confirmed. Version: 1.88.0 (system setup) {
"version": "0.2.0",
"configurations": [
{
"name": "Python Debugger: Current File with Arguments",
"type": "debugpy",
"request": "launch",
"program": "${file}",
"console": "integratedTerminal",
"args": "${command:pickArgs}"
}
]
}
|
this is an issue on OSX too. the following is a work around i used in my launch.json `{
}` my setup |
Same issue on Windows 11. It was all running fine on some older version, hadn't written any python for a while, and I accepted the offer to upgrade everything when I fired up VSCode. Then suddenly I can't debug python anymore. Unfortunately I don't know which the old versions were. My setup is now: Windows 11 Version 23H2 (OS Build 22631.3447)
I don't know if it's the same cause, but this issue seems to be reported here (microsoft answers) and it is attributed to the Python extension rather than the debugger..? However the suggest workaround (roll back to an ancient version) no longer seems to work (it fails to install for me). |
Since you have multiple arguments, list syntax (brackets around multiple comma-separated values) is what you should use (and served as a workaround in my case even when there is one argument). Thanks for the tip about the single quotes but see if this more typical syntax also works: "args": ["-f", "/Users/user1/My folder/test.bin"] |
@Poikilos The issue is not with args. Args is known by people, I hope. The issue with the path to python. I do not know how/where adjust that besides renaming folders. In my case a user name was created with space and it starts from there. |
Yes, I'm aware it is with the Python path, but in my case, changing the args syntax actually affected whether it could find Python. There is some type of cross-talk (command-splitting behavior changes for the whole command when the args is a string vs a list). My earlier comment gives an example, and may help the devs diagnose the issue. |
Interesting... will try. |
@Poikilos Yes, interesting - I can confirm that this works for me: This is working for me.... |
@tjohnsonhvac Thanks, but lol, same as my workaround cited in da151575's comment directly before yours 😆. To bump the issue maybe instead say "issue and workaround confirmed in version ..." and/or add thumbs up the issue. |
With powershell I get the following error
With command prompt I get the following error
|
I believe this deserves an integration test, this is a very basic and core feature thats failing (with the defaults). |
The setting, "${command:pickArgs}". Can it parse multiple args? |
@xlbljz - since this is a long thread could you create a new issue in regards to this problem or ask in the discussions sections of this repo. Thanks! |
Environment data
VS Code version: 1.86.2
Extension version: v2024.0.0
OS and version: Windows 10 Pro Up-to-date
Python version: 3.12
Shell: Powershell 7.4.1
Type of virtual environment used: venv with space in path.
Expected behaviour
The Python debugger should correctly quote paths that contain spaces in the Python interpreter path and the program to be debugged, ensuring commands are properly executed when arguments are taken through a launch.json configuration.
Actual behaviour
When there are spaces in the Python interpreter path or the program name, the debugger command fails due to improper quoting, leading to errors in execution.
For instance, if one's path for the interpreter were
c:\Users\one\Documents\Python Folder\.venv\Scripts\python.exe
, the error message they would receive would beAdditional detail
Currently one can side step the program issue by using escaped quotes but I have not found a method to have the venv executables path be quoted correctly.
Steps to reproduce:
Note: This also happens with manually hardcoded arguments.
The text was updated successfully, but these errors were encountered: