launch.json properties with multiple interactive variables break debugging

[taradinoc]

Issue Type: Bug

If one of a launch configuration's properties uses multiple interactive variables, the expansion will fail: vscode won't call the command or start a debug session.

For example, storyFile here causes the issue, but works as expected if I remove ${command:zversion}.

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "zil",
            "request": "launch",
            "name": "Launch in Z-Machine debugger",
            "storyFile": "${command:basename}.z${command:zversion}",
            "debugFile": "${command:basename}.dbg",
            "stopOnEntry": false,
            "predictableRandom": false
        }
    ]
}

Looks like these are matched with a greedy regular expression, so everything from the first ${ to the last } is merged into one variable reference: https://github.com/Microsoft/vscode/blob/1.21.0/src/vs/workbench/services/configurationResolver/electron-browser/configurationResolverService.ts#L237

VS Code version: Code 1.21.0 (9a199d7, 2018-03-07T11:04:09.969Z)
OS version: Windows_NT x64 10.0.16299

System Info

Item	Value
CPUs	Intel(R) Core(TM) i5-7600K CPU @ 3.80GHz (4 x 3792)
Memory (System)	31.95GB (16.67GB free)
Process Argv	C:\Program Files\Microsoft VS Code\Code.exe
Screen Reader	no
VM	0%

Reproduces without extensions

[isidorn]

@taradinoc you are correct.
We accept PRs that fix this.

[isidorn]

@weinand is there some special reason why this was assigned to March?
The way that delicate code is written is to not support multiple interactive variables per one field. Due to that and only 1 user complaining I am not so passionate about fixing this. Though I do accept PRs.

[weinand]

If this bug would only affect "interactive" variables, I would certainly agree.

The problem is that the term '"interactive" variables' is misleading because it really means "commands" (and the "interactive" ones are just a small subset).

So if an extension "blue" provides (non interactive) commands that surface interesting information that can be used in a launch config, it is confusing that "${command:blue.home}/${blue.version}/abc.blue" fails silently whereas "${env:blue-home}/${blue.version}/abc.blue" works fine.

I was under the impression that all variables are pattern matched by the same regular expressions and that a fix would be trivial. But it seems that different pattern matching code is used for commands.

I suggest that for March we show at least an error alert in this case before aborting the debug session. And then label this item as debt.

[isidorn]

@weinand Thanks for the explanation.
I have pushed a fix to not so greedliy match, and to basically use the same regex pattern as in other cases.
So your @weinand example should work now. However what still will not work is evaluating multiple of different commands in the same field. If they are the same commands it should work.