It turns out this optimization brings in a breaking change: `$MyInvocation` is different comparing to before the optimization change. I tried to fix the breaking change, but couldn't without introducing more hacky code. Given that, that PR should be reverted.
* Update 'Microsoft.PowerShell.CoreCLR.Eventing' to resolve conflicts
* Add reference to 'System.Diagnostics.EventLog' to build Microsoft.PowerShell.Commands.Diagnostics on Unix
* Stop compiling Get/New-WinEvent on Unix
This is based on an issue, where Enter-PSHostProcess on a locked down (WDAC enforced) machine allows any admin to connect to any another local hosted PowerShell process and execute commands as that user. This amounts to privilege escalation on the policy locked down machine and something we want to prevent.
Fix is to check for system lock down and disable Enter-PSHostProcess cmdlet with an error message.
`Read-Host` calls into `$Host.UI.Prompt()`. However, this method is also used when the host prompts for mandatory parameters that aren't provided. The method expects to be called when given a `FieldDescription` and if the input starts with `!` it enters `CommandPromptMode`. In this mode, you can type `!?` to request help, for example. However this mode is not something you can use via `Read-Host` (only if calling `$Host.UI.Prompt()` directly passing in a well constructed `FieldDescription`). When using `Read-Host -Prompt`, the cmdlet creates a `FieldDescription` where the name is the prompt and the rest of the properties are empty.
The fix is that if `Label` is empty, we can assume it's being called from `Read-Host` rather than being called to prompt for a mandatory parameter and thus not enter `CommandPromptMode`.
* return correct casing of filesystem path during normalization
* handle UNC case
* handle case to add trailing separator back
* add support for NTFS streams syntax
* add case-sensitive test
* only apply correct casing to directories
* handle 8.3 path syntax
* fix short path processing
This PR does 4 things:
* Adds a new cmdlet `New-PSBreakpoint` which creates new `Breakpoint` objects and writes them to the pipeline
* Adds a `-Breakpoint` parameter to `Debug-Runspace` which will receive `Breakpoint` objects
* Makes the constructors for `*Breakpoint` public for use with the API
* Makes `Debugger.GetBreakpoint(string id)` and `Debugger.GetBreakpoints()` public since `SetBreakpoints` is public
Note: `New-PSBreakpoint` and `Set-PSBreakpoint` (which already exists) are similar... but `Set-PSBreakpoint` also sets the breakpoints in the _current_ runspace. This is not ideal if we want to set breakpoints in a _different runspace than the current one_.
## PR Context
The "Attach to process" debugging experience in the PowerShell extension for VSCode is _ok_ but it's not great.
The reason it's not great is due to the `BreakAll` feature of PowerShell debugging which, when you run `Debug-Runspace`, will break at the first piece of code that gets run. This is not ideal when you "Attach to process" _and then_ run your code in the other runspace.
Today, the experience drops you in `PSReadLine`'s psm1 if PSRL is available or in the vscode PowerShell helper psm1.
It's unexpected for the user and not ideal.
This PR will allow the extension to pass in the breakpoints that need to be set initially with `BreakAll` turned off for none of this silly behavior.
### Silly behavior example
If you want a repro, try this:
PowerShell instance 1:
```
Enter-PSHostProcess -Id $otherprocesspid
Debug-Runspace 1
```
PowerShell instance 2:
```
./runfoo.ps1
```
Note that you end up NOT `runfoo.ps1`
Moved check if able to write to $PSHome as way to skip test to `BeforeAll` which already contained a check if running on Windows.
## PR Context
As part https://github.com/PowerShell/PowerShell/pull/9279, tests were updated to be skipped if the test requires writing to `$PSHome` but is not able to. However, these tests already had a skip mechanism in place so the additional check caused the test to run when it should have skipped.
Co-authored-by: Travis Plunk <github@ez13.net>
Add two properties in `ProviderInfo` class: `ItemSeparator` and `AltItemSeparator`.
On windows, the default values for those two properties are `ItemSeparator = '\'` and `AltItemSeparator = '/'`.
On unix, the default values for those two properties are `ItemSeparator = '/'` and `AltItemSeparator = '\'`.
Registry provider is the only exception, both properties for it have the value `\`.
Dongbo Wang