- Added OutputType attribute.
- Cmdlet adds the PSExtendedError typename and removes Exception and ErrorRecord typenames so that the formatting is used. The formatter then removes PSExtendedError and puts back the original typename so that $Error should be the same before calling Get-Error.
- While testing, had to make some changes to how InvocationInfo is retrieved so that ParseException which contains a nested ErrorRecord which as InvocationInfo is handled correctly.
- Combined Exception and ErrorRecord formatter into one.
Prior to this change, Group-Object -AsHashtable -CaseSensitive would give a key duplication error when given entries that only differ by casing. This was due to always using a case-insensitive hashtable, despite the request for -CaseSensitive behaviour.
ConciseView shows MyCommand as the prefix to the error message, but for a scriptblock, MyCommand is the whole scriptblock. Fix is to use CategoryInfo.Activity if available first. Also handle case where it's a script function by seeing if it's a command and showing MyCommand in that case rather than the Activity.
* Add -SkipHttpErrorCheck to web request cmdlets
The -SkipHttpErrorCheck flag causes web request cmdlets
(Invoke-WebRequest and Invoke-RestMethod) to ignore HTTP statuses that
are error statuses and treat them as successful requests. This allows
users to handle the responses using their own error handler and gives
them access to the full, unmodified response body and headers.
* Add -ResponseStatusVariable to Invoke-RestMethod
This allows the user to specify a variable to set to the integer value
of the respons's status code, Analogous to using
-ResponseHeadersVariable to retrieve the headers of the response. This
can be used to distinguish error messages from success messages when
used with -SkipHttpErrorCheck.
* Fix coding-style error
The summary for the SkipHttpErrorCheck property didn't conform
to style guidelines. This changes the summary to start with
"Gets or sets".
* Add tests for -SkipHttpErrorCheck
This flag supresses terminating errors on web cmdlets.
The tests are written to check that it properly
supressed the errors.
* Add test for -StatusCodeVariable
Th -StatusCodeVariable parameter specifies an output
variable for the status code with Invoke-RestMethod.
This test makes sure it functions properly.
* Fix typos and style for -SkipHttpErrorCheck tests
Variables had different cases from each other and some parameter
names were lower case.
* Fix typos and style for -StatusCodeVariable test
Variables had different cases from each other and some parameter
names were lower case.
* Add failure tests when missing -SkipHttpErrorCheck
These tests ensure that Web Cmdlets fail when -SkipHttpErrorCheck
is missing.
* Clean up tests for -SkipHttpErrorCheck
Per discussion on the pull requests. This commit fixes up
style problems with the tests for -SkipHttpErrorCheck.
* Add more status tests for -StatusCodeVariable
Previously, the -StatusCodeVariable flag in Invoke-RestMethod
only had tests for 200 status. This commit adds tests for 404
and 500 statuses and removes -SkipHttpErrorCheck from the 200
check.
* Fix response body in -StatusCodeVariable test
The test was copy/pastes from the 200 status test. The body
indicated success. This commit fixes that so it is also an
error indicator.
ConvertTo-Json doesn't allow $null to be passed in even though it can be valid resulting json. Fix is to remove the check that the input is not null. NewtonSoft.Json handles it just fine.
Add a test for the even handler leaking fix addressed in #10626https://github.com/PowerShell/PowerShell/pull/10626
The test is added to verify that PowerShell unregister the 'AppDomain.ProcessExit' event handler when a Runspace closes.
* Enhance enum FileDesiredAccess with zero value GenericZero
* Use the GenericZero as desired access mode to read reparse point without access it
From docs:
If desired access is zero, the application can query certain metadata such as file, directory, or device attributes without accessing that file or device, even if GENERIC_READ access would have been denied
Clear-Host on Unix calls clear command which issues escapes. Before the change we write them to PowerShell output stream and it could be unwantedly intercepted. After the change we write the escapes directly to console.
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.
- Adds `LanguagePrimitives.IsNullLike()` method to account for `DBNull.Value` and `NullString.Value` so that they can be considered the same as a null value where sensible in PowerShell.
- Updates `-ne` and `-eq` binders to treat `DBNull.Value` and `NullString.Value` as equal to null/AutomationNull.
- Update code paths for comparing objects in LanguagePrimitives to ensure consistency with how the `-eq` and `-ne` binders work when calling LanguagePrimitives methods to do the comparisons.
- Make `LanguagePrimitives.IsNull()` and `LanguagePrimitives.IsNullLike()` public methods.
- Added tests for null behaviours in `NullRepresentatives.Tests.ps1`
.NET Core changes to return "shortest roundtrippable string" by default for the ToString() method of double and float types. This results in ToString() for double/float values sometimes return a string in 17-digit/9-digit precision format. This PR updated the double/float-to-string conversion in PowerShell to continue using the old precision specifier before the change in .NET Core 3.0.
`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`.
Expands line continuance for pipelines to allow lines to continue automatically without backticks with the pipe symbol at the start of a line.
This adds to the existing functionality where pipes can be used to continue lines by placing them at the end of a line.
* 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
Re-add wildcard when searching AST + Missed test case.
## PR Context
In #8109, we removed the line that added a wildcard to the end of the command that was used to match commands in the script AST. This readds that line closer to where it is used.
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`