python.languageServer setting: JediPutting "\s" anywhere in an argument in the "args" list of the launch.json file will then pass that argument "\s" to the python file I'm debugging
Instead, "" is passed as an argument to the python file
You will notice that instead of "\s" being passed as an argument in the terminal, "" is passed (Just two double quotes)
I have also tried this with double backslashes.
Using the same steps as above, but instead, I put "\s" in the "args" list.
This also didn't work, and I saw that "\s" was passed to my python file in the terminal.
I added another slash, but "\\s" that only resulted in "\" being passed to my python file.
All I want is for "\s" to be passed as an argument to my python file.
In launch.json:
"args": [
"\s"
]
In Python Debug console: (Generated by the vscode-python extension)
cd /PATH/TO/DIR/src ; env /PATH/TO/PYTHON/python /Users/USERNAME/.vscode/extensions/ms-python.python-2020.7.94776/pythonFiles/lib/python/debugpy/launcher 50448 -- /PATH/TO/PYTHONFILE/foo.py ""
In launch.json:
"args": [
"\\s"
]
In Python Debug console: (Generated by the vscode-python extension)
cd /PATH/TO/DIR/src ; env /PATH/TO/PYTHON/python /Users/USERNAME/.vscode/extensions/ms-python.python-2020.7.94776/pythonFiles/lib/python/debugpy/launcher 50448 -- /PATH/TO/PYTHONFILE/foo.py \\s
In launch.json:
"args": [
"\\\s"
]
In Python Debug console: (Generated by the vscode-python extension)
cd /PATH/TO/DIR/src ; env /PATH/TO/PYTHON/python /Users/USERNAME/.vscode/extensions/ms-python.python-2020.7.94776/pythonFiles/lib/python/debugpy/launcher 50448 -- /PATH/TO/PYTHONFILE/foo.py \\
The correct syntax is this one:
"args": ["\\s"]
Because JSON itself treats \ as a special character, so you need to escape it if you intend to use it verbatim.
The reason why the command line VSCode generates contains \\s, is because it is in turn escaping it for bash, which also requires backslashes to be escaped. If you do print(sys.argv[1]) from inside Python, it should have the value that you expect.
Yes, that seems to work. Thank you!
I'm bit confused, because that argument _was_ passed to python in double quotes, so the backslash shouldn't need to be escaped, right?
I'm still having issues with other characters _not_ being escaped for bash by vscode, like the ampersand "&" symbol and the exclamation mark "!".
In launch.json:
"args": [
"abcde&fghijk"
]
In Python Debug console: (Generated by the vscode-python extension)
... foo.py abcde&fghijk
The ampersand symbol has a special meaning in bash, so it needs to be escaped. The extension doesn't do it automatically, so I tried manually escaping it, "args": ["abcde\\&fghijk"]. (An extra backslash to escape the other, for JSON)
This didn't work either, and the command generated by the extension was: ...foo.py abcde\\&fghijk, which makes bash ignore the backslash, and so the ampersand still causes a problem.
For bash at least, double quotes don't disable escaping - only single quotes do. So echo \\s is equivalent to echo "\\s" and to echo '\s'.
Other special symbols like $, (), and & are a bit different - there are some scenarios in which you want them to not be escaped (so that shell can perform variable and subshell expansion, for example), and others when you do want to pass them verbatim to the app.
So, the debugger now allows you to control that by specifying "argsExpansion": "none" in your launch.json. The default setting is to enable shell expansion, because that's what the extension was doing before the setting was added, and we didn't want to break people with pre-existing launch.json configs relying on that behavior.
Thanks, that solves my problems.
Shouldn't "argsExpansion": "none" be included by default, in launch.json?
Not _the_ default, but included in new launch.json files my default. That way it wouldn't break any pre-existing launch.json configurations.
We don't have clear evidence that one or the other is preferable by default. There was one beta of debugpy which didn't do any expansion, and there were bugs filed about it, as well. We're sticking to pre-existing behavior on the basis that it's at least what more users are familiar with, whether they prefer it or not.