code-debug
code-debug copied to clipboard
WebFreak001
make command line arguments according to vscode debugger documentation (once created)
@WebFreak001 Thanks for adding this. I got this to work as "arguments": "arg1 arg2 arg3",
but first I tried "args": ["arg1", "arg2", "arg3"],
which is how it's done in the tasks.json file. Is there some reason for not doing it the same way as in that file?
If there is a need for pipe I/O, I'd suggest checking if there is already a precedent for how to specify that, and if none, use another parameter like "pipein": ...
One problem with putting all the arguments as well as pipe connections in one string is that it is unclear how it is parsed and evaluated. For example, how would one specify a null string argument for a command like xcommand -d "" arg3?
Also, the hover help should be more detailed. It should show an example of how to pass more than one argument.
Yes, i did it like this because GDB has its own parameter parser and i cant pass arrays of strings into it, instead just that one. It also supports piping like this which would be weird with a string[]
There may be some bugs related to how args are passed to programs. See https://github.com/Microsoft/vscode/issues/4057 where I had problems passing file paths to a PowerShell script.
well from those things probably only \\ will be a problem with GDB.
GDB has a parser for arguments in it like bash/sh. So basically it will be exactly the same as appending the arguments after the function name in the console. There shouldn't be any problems there except passing the arguments into the json file which obviously requires escaping \
I still think there is a need for some documentation of the launch.json file format. I filed an issue detailing what documentation I (as a VSCode user) would like to see. Please see Microsoft/vscode-docs#230 My preference would be to have that be documented once by the VSCode project, and extension projects would only need to document the ways in which their implementations differ from the VSCode standard. What do you think? :-)
The documentation in general is code-debugs job but having some standard documentation to base the code on would be really useful and would make debuggers more intuitive
I'd suggest supporting "arguments" : ["arg1", "arg2"...] syntax if at all possible, even if you also support "args" as a string and internally the array form just concatenates the array. The advantage would be that you'd get free integration with test explorers (in particular, I'm thinking of the CMake Test Explorer extension) which use a template debug configuration and populate the arguments with an appropriate filter expression to run the specified test.
This issue is only about additional supporting arguments as array, and then concatenate those to the string, possible with quoting, correct?
A secondary type is easy to implement, as seen with the new stopAtEntry configuration.
