"$("(")" is reporting 'the string is missing the terminator: ".' and "$(subexpression) is missing the closing ')'."

[AndrewGaspar]

This expression is causing two errors with syntax parsing in VS-Code:

• 'the string is missing the terminator: ".
• $(subexpression) is missing the closing ')'.

"$("(")"

Maybe there is some weirdness with bare ( in PowerShell string literals that I'm not aware of, but this seems wrong to me. No amount of escaping seems to resolve the issue, either. In the PowerShell prompt, pressing Enter after entering this text displays the multi-line input prompt, indicating that the shell also thinks the input is incomplete.

This repros with any size string literal, as long as there is an unbalanced OPEN parentheses inside the string.

[MikeShepard]

When I enter that in the ISE (5.0), I get an error about the subexpression missing the closing ).

[MikeShepard]

To me, this looks like a double-quoted string with a subexpression $( started, then a closing double-quote. That's an error.

After that, there's a left paren and a right paren in quotes, but no closing paren (since the right one was in quotes).

[AndrewGaspar]

Maybe these examples are more clear. They also repro the issue.

"$(" some text here ( and also here ")"

"$(" a string literal " + " some text here ( and also here ")"

[MikeShepard]

The way I parse it (and PowerShell seems to agree) is a $( inside double-quotes followed by some other stuff.

I don't know of a way to include a double-quoted string literal in a subexpression in a double-quoted string.

I would think replacing the "inner" double quotes with single quotes would work, but it doesn't:
"$(' a string literal' + ' some text here ( and also here ')"

that gives the same error. I think that is actually a bug, but I don't think the same thing with double quotes inside.

does that make sense?

[rkeithhill]

You can put a double quoted string inside of a sub-expression inside of a double quoted e.g.:

"$("foo`nbar`n"*2)"

Regardless the apparent bug in parsing is not a bug with this extension as it is using the same parser/AST that the console's PSReadLine and ISE are using. Both of which choke on the same unbalanced paren.

You should file this bug on the PowerShell UserVoice site

[AndrewGaspar]

Sounds like PowerShell needs to be open sourced! ;)

Bug filed here: https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/11297838-parsing-error-on

[daviwil]

Great discussion! I'll close this issue since Andrew has filed the issue on the UserVoice site.