Prompt functions that return something other than string cause an InvalidCastException

[rkeithhill]

I was trying to debug some Pester tests while using latest PSES bits and was getting stymied by my breakpoints never getting hit. When I commented out the bundledModulesPath setting and went back to using 0.8.0, my breakpoints were hit.

Should be able to repro this with the Plaster repo, opening debugHarness.ps1 and uncommenting the code that invokes Pester. Set a breakpoint in one of the *.Tests.ps1 files and see if it gets hit.

[daviwil]

Hmmm, I just tried setting a breakpoint in a test in ConditionEval.Tests.ps1 then ran debugHarness.ps1 with the Invoke-Pester call uncommented, the breakpoint got hit for me. Could you try it again with Verbose logs on and email the logs to me? Could be something weird going on that I'm just not seeing here.

[rkeithhill]

Will do. I should have that by later tonight.

[rkeithhill]

1484702865-7a0f361c-6146-4030-afcc-c613a719e28c1484600221675.zip

Here ya go. It looks like an exception in the posh-git prompt function might be at fault.

[daviwil]

Looks like the prompt function is returning a list of results rather than a string so it broke my prompt handling function. About to send a PR.

[daviwil]

So one thing this did point out to me is that I turned debugger prompts back on by default after we decided to turn them off in issue #130. The main reason for doing this was that I wanted the remote session / entered process prompt to be displayed so that it's obvious the user is in a non-default session. We currently don't have a better way to do that in the debug console.

It looks alright until a prompt function causes an exception which makes us write out a "default" prompt function of PS>. Since we're ripping the angle bracket off the end of that string to make the prompt look a bit less like a prompt, the posh-git tests just have a bunch of lines containing PS written out when you're stepping through the code. Kinda ugly.

I think there are two options:

1. Go back to the previous behavior of not writing out prompts when the debugger stops. I'm not crazy about this because I think we need that information.
2. If we ever end up with a default prompt string of PS, just don't write it out. This is better but might be confusing if the user's prompt doesn't write out for some reason.

Maybe a third option could be to write out a more obvious default prompt string? Any ideas there?

[rkeithhill]

I believe we still have some issues with the "default prompt" that posh-git installs. Regarding the prompt, I think that a "conventional prompt" isn't the right thing to display whether it's the user's prompt or one provided by PSES. I would find it useful to see what type of breakpoint was hit and at what location (file:line). So yes on # 3 if you can override the prompt function to display this information e.g.:

Hit line breakpoint in 'C:\Users\Keith\PowerShellSupport\VariableScopes.ps1:9'

[daviwil]

Hmmm, good point. Though this causes us to lose some of that session connection info if we don't spit out the prompt. Unfortunately I don't always have the necessary context to know when I'm in a remote session so that we only print it out when we're in a non-default session. And there's always the chance that the prompt function in any session could throw an error which would cause the prompt to be useless again.

I'll have to think about this a little bit.

[rkeithhill]

So no way to override the session's prompt with one from the extension? I don't think you'd even need to bother to put it back to the original until we have the interactive console.

[daviwil]

I don't have to run the prompt function at all, I'm just trying to find a way to preserve the information that I can get from the prompt in the cases where I need it. Maybe I don't need it, but I'm still trying to decide whether it's more costly (or inevitable) to gather the information that I'd otherwise get from the default prompt.

[rkeithhill]

Many folks override their prompt in their global profile.ps1 file. And many I've seen don't bother checking if the session is currently stopped at a breakpoint (no [DBG]: ) or has a nested prompt e.g. >>.

What information are we trying to preserve? Path? That is the common thing displayed in the prompt.

[daviwil]

Nah, the session connection information, like [localhost][Process:29331], etc. With the new remote/attach debugging features this information is pretty critical to knowing where you are at the moment.

[daviwil]

And AFAIK those bits of info get written out by PowerShell regardless of what the user's prompt function returns.

[rkeithhill]

Oh that info. Yeah, that would be good to have. :-)

AFAIK those bits of info get written out by PowerShell regardless of what the user's prompt function returns.

I believe that is correct since the default prompt does not have that info:

[runspace]::DefaultRunspace.InitialSessionState.Commands['prompt']


Definition  :
              "PS $($executionContext.SessionState.Path.CurrentLocation)$('>' * ($nestedPromptLevel + 1)) ";
              # .Link
              # http://go.microsoft.com/fwlink/?LinkID=225750
              # .ExternalHelp System.Management.Automation.dll-help.xml

[daviwil]

OK, I think I got it cleaned up pretty nicely, it looks like this now when you hit a breakpoint:

[DBG]: [Process:4952]: [Runspace1]: Hit Variable breakpoint on ':$i' (Write access)

If you're stepping through the code no prompt will be written out because the stop wasn't caused by a breakpoint. If you run a command in the console, the real prompt will get written out after the command completes. I'm pretty happy with this solution, sending a PR in a minute.

[daviwil]

PR is here: #344