@microsoft-github-policy-service agree company="Software Mansion"

One needs to have in mind that the custom command needs to return output in the same format as currently used commands do

This would lead to more issues for users tyring to get their command to match what PsProcessParser expects and make it difficult for the extension authors decide to add more columns to the process listing. If more columns were added or reorganized, this would also lead to breaking user's launch.jsons customRemoteProcessCommand.

We would reccomend writing a vscode input variable instead, as users can run their own vscode command and parse their own ouput to the value they want for the launch.json.

https://code.visualstudio.com/docs/editor/variables-reference#_input-variables

E.g. launch.json

{
  "configurations": [
    {
      "type": "cppdbg",
      "request": "attach",
      "name": "Run Program",
      "program": "${workspaceFolder}/a,out",
      "processId": "${input:pickProcess}"
    }
  ],
  "inputs": [
    {
      "id": "pickProcess",
      "type": "command",
      "command": "extension.my.cysto.testPicker"
    }
  ]
}

what about forcing such custom command to return data as CSV? Having this implemented for custom command will avoid this issue

what about forcing such custom command to return data as CSV? Having this implemented for custom command will avoid this issue

That sounds good, I think there also need to be an associated field indicating the format of the output.

E.g.
$PID,$EXE,$CMDLINE
and use a custom parser find those token and create the correct Process object.

Another question is that is there a reason why ToyBox's ps deviates from the standard usage? Is there a good way to detect that the ps being used is ToyBoy's version?

@WardenGnaw I've changed implementation to just support Toybox detection and proper command for getting remote process list.

For some reason Toybox's ps works in a bit different way.