Breakpoints not honored in file name with square brackets in name

[rkeithhill]

In testing the ${file} way of specifying the file to debug, I'm noticing that for a file named foo[1].ps1 the breakpoint never hits - even though the script clearly executes. And while VSCode shows the file as having a breakpoint, if I run Get-PSBreakpoint in the dbg repl, it doesn't show up. My guess is that were we set the breakpoint file we probably need to use -LiteralPath instead of -Path.

[daviwil]

Hah, great catch!

[rkeithhill]

@daviwil Check this out. Create a file in ISE - name it foo[1].ps1. Now put a few lines of script in it. Put the cursor on a valid line of script and press F9. Nothing!! No breakpoint. Turns out that Set-PSBreakpoint doesn't have a Path/LiteralPath set of parameters (bad, bad cmdlet). For files it has a -Script parameter that gets tripped up by globbing chars. If you try to set the breakpoint from ISE's command window, it smartly escapes the square brackets and puts the path in a string:

5> Set-PSBreakpoint -Script 'C:\Users\Keith\PowerShellSupport\foo`[1`].ps1' -Line 2

That works.

From the PowerShell prompt, only this combination seems to work (path in quotes and escaped brackets). Blech. The CompletionText for that path has the correctly quoted/escaped string. I wonder if we could somehow use that for processing file paths before passing them to Set-PSBreakpoint? Hmm...

[daviwil]

Haha, using IntelliSense to resolve the path might be a little overkill, but we should definitely quote and escape any path that gets passed in. If you want to try the IntelliSense approach just to see how the code looks, go for it!

[rkeithhill]

OK fixing it the right way should be easy. I believe the only wildcard chars we need to escape are [ and ].

[daviwil]

Sounds good to me!