PSRP currently relies on XML for the transport messages. When using PSRP over SSH, if the target side fails, it sends back a text message. PSRP sees this and doesn't know what to do so it throws
a generic message which makes troubleshooting the issue more difficult. Change here is to throw
the text message which now looks like:
>new-pssession : [test-machine] There is an error processing data from the background process. Error reported: Invalid argument '-np', did you mean:.
Previously:
>new-pssession : [test-machine] There is an error processing data from the background process. Error reported: Cannot process an element with node type "Text". Only Element and EndElement node types are supported..
Since it's processing one line at a time, not able to get the whole message.
* [FEATURE] Allow Basic Auth over HTTPS
* WSManTransportManager.cs: Simplify HTTPS check
Update comment in test to refer to the right exception type.
* Disable test until limi crash fo selected connection error paths is fixed
* Use Hex format for defining the expected HRESULT
The fix causes a problem in debugging. When stepping over the scripts in debugging mode, the debugger will stop at the switch statement condition expression twice at the very beginning -- one for evaluating the condition, and one for iterating the condition.
Table formatter was overly aggressive in removing padding so even right justified output (default of numbers) gets incorrectly stripped of padding. Fix is when right justified, always add padding (because it's right justified, there's never trailing whitespace).
* Implement location history feature for Set-Location.
This makes it possible to go back to the last directory using 'cd -',
which is exactly the same syntax as on Linux shells.
* Use an existing stack implementation instead of relying on an environment variable and move logic for 'cd -' into the internal class of SessionState.Path.SetLocation
Keep the (additional) setting of an environment for Unix system in case of mixed usage of cd and Set-Location to provide consistency.
* Use a bounded stack with a limit of 1000 and adapt tests.
Remove setting environment variable on Linux as discussed in PR.
* Fix test: use get-location explicitly to avoid subtle difference in the path string (e.g. an additional slash at the end)
Make syntax to .net call of environment consistent with surrounding code
* Move initialization of _workingLocationHistoryStack into constructor of SessionStateInternal and set the limit to 20 as discussed in PR 5051.
* Make new BoundedStack class in engine utils internal
setdate.cpp was incorrectly assigning an int to a struct, fixed to initialize struct zero'd
update the typegen project in the bash script
added some help text at top of script for someone trying to build it
updated runtime to linux-musl-x64 instead of linux-x64 as Alpine distro uses the musl libc libraries instead of glibc which is used by most distros.
* Fix error when using Get-ChildItem c:
* Fix New-Item test issue.
* Add tests for Get-ChildItem cmdlet.
* Add tests for New-Item cmdlet.
* Fix tests for New-Item cmdlet.
* Fix for #4520 '-ArgumentList should accept @() or $null'
Removed the [ValidateIsNotNulOrEmpty] attribute from the parameter.
* Fixed null and @() empty list tests to not both test null
* [Feature] Fixed test issue on non-Windows; added code to suppress displaying new windows on Windows.
Measure-Object should handle `ScriptBlock` properties. Fixed by renaming `MshExpression` to `PSPropertyExpression` and making it public. Then in `MeasureObjectCommand`, lifting it up to the parameter level. Previously the implementation exposed the Property as a string and
wrapped it internally as a `PSPropertyExpression`. Now the parameter type is `PSPropertyExpression` directly allowing for both wildcard strings and `ScriptBlock`.
`PSPropertyExpression` now lives in a public namespace where it can be used by cmdlet and script authors to easily add the same type of functionality to their commands. I also modified `PSPropertyExpression` to handle hashtables properly as objects so
@{prop = 3} | measure-object prop
and
@{prop = 3} | measure-object {$_.prop}
will work the same. (Previously the example using just the property name would fail.)
This addresses issue #6207. During SSH remoting on Linux machines, when PowerShell on the client creates the SSH process to connect to the target machine, it was not passing in environment variables from the parent process, and this was preventing ssh-agent key management from working.
This change adds a helper function to create environment variable key/value pairs for the created SSH process, based on the passed in ProcessStartInfo object.
- Use File.GetAttributes() instead of p/invokes to check for existence of FileSystem items. The method throws access exceptions which we use for better error messages.
- Remove the word 'Native' from method names.
- Remove isolation attribute from Analytic and Debug channels. These channel types always have an isolation of Custom, regardless of what is put here in the manifest.
- Since no events are being written to the Admin channel currently, remove it. This avoids the Windows Event Log pre-allocating a file for the channel.
Dynamic (DLR) objects work in some places today, but not others. This change expands that support to ForEach-Object, Where-Object and the family of cmdlets that use 'MshExpression' (Select-Object, etc.).
This change addresses both wildcard and non-wildcard cases. In wildcard cases, it uses the existing support of generating PSDynamicMember objects for names returned by GetDynamicMemberNames.
In non-wildcard cases, a dynamic property access is attempted whether or not the name shows up in GetDynamicMemberNames, but a truly "blind" access is only attempted if we see that the base object is an IDMOP. If the dynamic access fails, you'll get the same or a similar error experience as before ("The property 'Blarg' cannot be found", or no error at all, depending on the cmdlet and the strict mode setting).
The included test coverage includes a stub for the.ForEach operator--once people are happy with this change, I can continue by adding support there.
This change should allegedly also have positive perf impact, though in actual perf testing, although it does seem ever-so-slightly faster, I found it difficult to measure much difference at all.
PowerShell serialization has a list of known PowerShell types. When an object is deserialized containing a known type it tries to deserialize the object to that specific type and throws an exception if it can't succeed. SemanticVersion only exists in PSCore6 so when remoting from Windows PowerShell or importing clixml generated from PSCore6 that contains SemanticVersion, it fails.
With this fix, it will be rehydrated as a "PSObject" with "Deseriealized.System.Management.Automation.SemanticVersion" in the 'TypeNames' in both Windows PowerShell and PowerShell Core.
Update links that contain 'en-us' culture to remove 'en-us' culture (if possible) and in some cases update to newer re-directed link to docs.microsoft.com
This fixes issue #6880 where user input interferes with the way the progress panel is displayed. If the user types any input while running a command displaying progress, that input would be echoed causing the terminal's cursor position to change. On the next progress write, output would be written using the new, incorrect cursor position. This had the effect of causing the progress pane to "march" across the screen if the user held down a key. The fix is fairly simple - update the physical cursor position right before updating the screen. This still leaves a very small window where an individual update might be off by a character or two but this is not cumulative and will be corrected on the next update. I've added code to SetBufferContents() to do this but only on UNIX. It's not a problem on non-VT100 style consoles.
After parsing `if () { }`, new lines are skipped in order to see if either `elseif` or `else` is present. When neither is present, we should resync back to the pointer before skipping those possibly available new lines, so that the new line tokens can be utilized by the subsequent parsing.
* Perform JumpList creation in background thread to improve performance when pwsh owns the window (i.e. when the Jumplist has to be created)
* Move JumpList creation to a later stage to allow for more code that might make it exit earlier as suggested in PR review by @iSazonov
To support PowerShell modules built with .NET Windows Compatibility Pack, we decided that it was best to ship the WCP assemblies with PS Core. This also adds many new .NET APIs be default while only adding ~3.5 MB additional disk footprint (to a ~137 MB install currently).
Also update the build to adopt the official .NET Core 2.1.
The cleanup is coming from a code review to cleanup psl. Here we clean up the side branch of the code that will allow later to clean up a branch which uses psl.
- IO.FileInfo does not make system calls in constructor. So we can create the object and then use the required attributes without direct call IO.FileInfo.GetAttributes() ( SafeGetFileAttributes() ). This allow us to exclude some p/invoke calls in our code in later cleanups. Also we get unified code for both Windows and Unix.
- Remove SafeGetFileAttributes() and WinSafeGetFileAttributes(). Currently .Net Core support file attributes on all platforms in fastest way and we can remove our workaround. We get a regression in rare case (for files like pagefile.sys). Fix is ready in CoreFX, we get it in 2.1.1. I suggest ignore the regression because this is a very-very rare situation (Get-ChildItem c:\pagefile.sys -Hidden). The .Net Core team was not even able to create an artificial test for such files and uses a real pagefile.sys file for the test. Also the enumeration is still working (dir c:\ -hidden).
- Re-add test which we lost in #4050. The test is pending because of the regression.
Closes#6649
This is a port of existing C++ Windows PowerShell code from MainEntry.cpp
Some of the code has been copied and minified from the WindowsApiPack.
The code is not compiled for Linux (not sure also another condition is needed for Windows on ARM?).
The code checks if the PowerShell process has a window handle by checking the startupinfo and only then tries to populate the list (and also checks if there is a slot available in the jumplist).
Tested on Windows 10 1803, jumpLists have been supported in Windows since Windows 7, which matches what PowerShell Core supports.
Steve Lee