Add -LiteralPath parameter to Set-PSBreakpoint #7995

Activity

1. Ilya (iSazonov)

   added

   Issue-Enhancementthe issue is more of a feature request than a bugthe issue is more of a feature request than a bug

   Area-Cmdlets-Utility

   on Oct 11, 2018
2. KirkMunro commented on Jul 11, 2019

   

   Kirk Munro (KirkMunro)

   on Jul 11, 2019

   Contributor

   More actions

   Set-PSBreakpoint doesn't have a path parameter either. It just has -Script (which is poorly named, given the confusion with the ScriptBlock type).

   To resolve this, I propose the following:

   1. Treat paths passed into Get-PSBreakpoint and Set-PSBreakpoint as literal paths.
   2. Update the -Script parameter on those cmdlets to accept pipeline input by property name.
   3. Add PSPath as a parameter alias for the -Script parameter on each of those cmdlets.
   4. Consider renaming -Script as -FilePath to match other PowerShell cmdlets that accept a literal path with no wildcard support, and add -Script as an alias for backwards compatibility.
   5. Consider adding a -Script (-FilePath) parameter that accepts pipeline input by property value with a PSPath alias in a new parameter set that would be added to Enable-/Disable-/Remove-PSBreakpoint to make it easier for users to turn breakpoints on or off or remove them according to their path with less pipelining.

   Rationale:

   • Since the -Script parameter (or -FilePath parameter if we rename it) accepts multiple values, it is trivial for users who actually want to set a breakpoint on multiple files to do so using other cmdlets that support wildcard paths, in a pipeline.
   • Today if someone wants to get/set/enable/disable/remove a breakpoint on multiple files, since -Script does not support pipeline input, and since that parameter isn't on the enable/disable/remove cmdlets, it is much harder than it should be to do that, requiring all files to be in the same folder or using a loop to set the breakpoints. These changes would make that much easier.

   As for risk, these are breakpoint cmdlets, which are intended for interactive use. Someone could have an automated process to set breakpoints on a bunch of files though as part of their dev/test cycle, and be interrupted by such a change. Still, that's dev/test, not production, and I think the risk is pretty low and worth considering.

   Thoughts?
3. rkeithhill commented on Jul 11, 2019

   

   Keith Hill (rkeithhill)

   on Jul 11, 2019

   Collaborator

   More actions

   Maybe these cmdlets should just define the normal Path/LiteralPath parameters and configure Script as an alias for one of the two?
4. KirkMunro commented on Jul 11, 2019

   

   Kirk Munro (KirkMunro)

   on Jul 11, 2019

   Contributor

   More actions

   My hesitancy there is:

   1. Parameter set bloat.
   2. The breakpoints that are created are associated with actual files, not wildcards,
   3. I sincerely doubt setting a breakpoint using a wildcard adds value today. It certainly doesn't for me, and if it does for others, it's limited to a single folder (i.e. if you want to limit breakpoints to your module, you need to use pipelines/other commands anyway to get all of the files in a folder hierarchy). Also, since it results in one breakpoint being created per file that matches the wildcard, it's not that user friendly. The only use case I can come up with where I might restrict breakpoints to certain files would be if I'm debugging a module and I want to scope breakpoints to all files within that module, which means structure, which means pipelining actual files, not wildcards.

   👍React with 👍1Reacted by Keith Hill
5. rkeithhill commented on Jul 11, 2019

   

   Keith Hill (rkeithhill)

   on Jul 11, 2019

   Last edited by rkeithhill

   Collaborator

   More actions

   Good point on not needing wildcard support. So OK, only need a Path parameter with the appropriate pipeline bindings and aliases for PSPath and Script.
6. rjmholt commented on Jul 15, 2019

   

   Rob Holt (rjmholt)

   on Jul 15, 2019

   CollaboratorAuthor

   More actions

   Wouldn't it be nice if a -Path parameter (perhaps with a certain attribute) implicitly included a -LiteralPath parameter. I'm sure there are flaws to that idea and here's probably a bad place to discuss it all in full, but just felt I should blurt it out.
7. microsoft-github-policy-service commented on Nov 16, 2023

   

   microsoft-github-policy-serviceBot

   on Nov 16, 2023 – with Microsoft GitHub Policy Service

   Contributor

   More actions

   This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
8. microsoft-github-policy-service commented on Nov 16, 2023

   

   microsoft-github-policy-serviceBot

   on Nov 16, 2023 – with Microsoft GitHub Policy Service

   Contributor

   More actions

   This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
9. microsoft-github-policy-service commented on Nov 16, 2023

   

   microsoft-github-policy-serviceBot

   on Nov 16, 2023 – with Microsoft GitHub Policy Service

   Contributor

   More actions

   This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
10. microsoft-github-policy-service

    added

    Resolution-No ActivityIssue has had no activity for 6 months or moreIssue has had no activity for 6 months or more

    on Nov 16, 2023
11. microsoft-github-policy-service commented on Nov 23, 2023

    

    microsoft-github-policy-serviceBot

    on Nov 23, 2023 – with Microsoft GitHub Policy Service

    Contributor

    More actions

    This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.
12. microsoft-github-policy-service

    closed this as completedon Nov 23, 2023
13. Ryan Yates (kilasuit)

    added

    WG-Cmdletsgeneral cmdlet issuesgeneral cmdlet issues

    and removed

    WG-Cmdlets-Utility

    on Jul 17, 2026