Makes remote attach picker respect the pipeTransport.quoteArgs config…

[mjrist]

Summary
Fixes #13791 by making the remote attach picker respect the pipeTransport.quoteArgs configuration.

[sean-mcmanus]

Does anyone know why it's specified as pipeTransport.quoteArgs.exceptions? Is true/false valid for quoteArgs?

[sean-mcmanus]

Should this be pipeTransport.quoteArgs?.exceptions?

UPDATE: Actually, it seems like the references to the "exceptions" object in quoteArgs should be removed? I don't understand why that was used.

At MIEngine I see it without "exceptions" so I think that should be removed: https://github.com/microsoft/MIEngine/blob/main/src/MIDebugPackage/OpenFolderSchema.json#L253

Although we could do that change as a follow up fix ourselves.

[mjrist]

@microsoft-github-policy-service agree company="SEL"

[Colengms]

It's worth noting that simply quoting or not quoting arguments is not a proper way to deal with whether arguments are expected to or expected not to potentially contain shell quoting/escaping. Whether or not arguments are expected to potentially contain or not to contain shell quoting/escaping, are mutually exclusive. (There's no auto-detect potential, as the same content could be interpreted differently depending on that assumption.)

https://learn.microsoft.com/en-us/archive/blogs/twistylittlepassagesallalike/everyone-quotes-command-line-arguments-the-wrong-way

https://daviddeley.com/autohotkey/parameters/parameters.htm

Adding quotes may deal with use of spaces, but not much else. In general, there should be a distinction made between args vs. command-line fragments. An 'arg' (alone) is a code-level concept and does not imply anything related to shell quoting/escaping. This would seem to be particularly true when referring to an array of args, which I would propose is explicitly not intended to represent use of those arguments on a shell command line. Command lines (and fragments) are specifically related to invoking a command line using a shell (at least on Linux and macOS. On Windows, the situation is a bit murkier, as the "shell" decoding is handled by a runtime library in the target process, which can depend on how the process was built). A 'command line (or partial/fragment)' is something that would be specifically related to passing something through a shell, and therefore shell escaping is expected to potentially be present already, if needed.

As long as these are clearly distinguished in the input, there are separate spawn/launch APIs (or options to those APIs) to identify whether the arguments should receive shell processing or not.

$0.02