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
* 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.)
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.
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
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.
Convert ShouldBeErrorId to Should -Throw -ErrorId in PowerShell tests.
Get rid of try { } catch { } formula to assert that errors were thrown.
Small fixes in tests to obey the new Pester -Parameter syntax.
closes#6728
Breaking change approved in #6728
This PR switches the logic of when the Web Cmdlets handle redirects when the Authorization header is present. .NET Core 2.1 no longer sends the Authorization header by default (dotnet/corefx#26864). however, we introduced the ability to do so leveraging the previous default behavior through the use of the -PreserveAuthorizationOnRedirect switch.
This PR also corrects a bug introduced 6.0.0 where certain redirect types redirect from POST to GET were set which should have passed through POST to POST and some were improperly passing through POST to POST which should have been doing POST to GET. This correction is a breaking change. It was made apparent as now the redirection behavior is being managed by CoreFX which is doing the correct behavior, tests were added for both when CoreFX and the Web Cmdlets manage redirection.
This regression was introduced by #6523, in `PSModuleInfo.cs`. A circular nested module check was removed because the comment there suggested it happens only with a deprecated workflow module. This causes a `StackOverflow` exception when running into circular nested modules.
Circular nested modules could happen for a module that is not well structured. For example, the module folder `test` contains two files: `test.psd1` and `test.psm1`, and `test.psd1` has the following content:
@{ ModuleVersion = '0.0.1'; RootModule = 'test'; NestedModules = @('test') }
The same value `test` is put in both RootModule and NestedModule, which will end up with a module whose nested module points to itself.
There are two changes in this PR:
1. Add back the check for circular nested modules in `PSModuleInfo.cs`.
2. Remove a wrong `Dbg.Assert` in `ModuleCmdletBase.cs` and two checks before it.
- For the assertion `Dbg.Assert(newManifestInfo.SessionState == ss`, when facing the example above, the nested module will first be loaded with a different session state, and then when trying to load the root module, the same loaded nested module will be reused for it. So 'newManifestInfo.SessionState' is not `ss`. The assertion will fail in that case.
- For the two checks before the assertion, they are not needed anymore based on the comments there.
* Build Update
- Change `TargetFramework` to `netcoreapp2.1` and removed unnecessary `RuntimeFrameworkVersion` from `PowerShell.Common.props`
- Update dotnet SDK to 2.1.300-rc1-008662
- Update `TypeGen` target in `Build.psm1` to work with 2.1
- Rename macOS runtime to `osx-x64` as the old build logic expects 10.12 and breaks running on 10.13 system.
- Remove `PackageReference` to `System.Memory` as it's part of dotnetcore 2.1
- Update search for `crossgen` executable to find the matching version
* Test Update
- Update test tools `WebListener` to latest `asp.net core`
- Marked `AuthHeader Redirect` tests as `Pending` due to change in CoreFX
Fix Select-Object.Tests.ps1 which might fail for Unix OS.
In the test, the processes which name matches i* are selected and it checks if there is non zero number of these processes. The test assumes that there is always at least one process, probably `init` - idle, but on Unix idle process does not have the name and hence the test might fail
- Can compile a source from strings (TypeDefinition and MemberDefinition).
- Can compile from files.
- Can compile only to a file (without loading the produced assembly).
- Do not recompile and don't reload if the sources have not changed.
- Implement `-IgnoreWarnings` to not treat warnings as errors. By default, the cmdlet considers warnings as errors.
- Add VisualBasic support.
- Add new `-CompilerOptions` parameter to allow setting Roslyn command line parameters including:
- Parser options.
- Compile options.
- Emit options.
**ATTENTION:** The `CompilerOptions` can be specified along with other options like `-OutputAssembly`, `-Language` and `-IgnoreWarnings`. The explicit setting parameters will take precedence over the same settings specified in `-CompileOptions`.
See docs about the compiler options:
https://github.com/dotnet/roslyn/blob/master/docs/compilers/CSharp/CommandLine.mdhttps://github.com/dotnet/roslyn/blob/master/docs/compilers/Visual%20Basic/CommandLine.md
**ATTENTION:** `-OutputType` default is `Library`. If `-OutputType` is absent the `-OutputType` default overlaps a value in `CompileOptions`. In other words output type ("target" ot "t" in command line) is always ignored in `CompileOptions`. We have to use `-OutputType` to set an output type.
These changes port Windows PowerShell support for Applocker and DeviceGuard User Mode Code Integrity (UMCI) to PSCore6. Windows PowerShell uses public APIs to determine if a system is in locked down mode via AppLocker or DeviceGuard, and automatically runs in constrained language mode. For more information about PowerShell constrained language, see: https://blogs.msdn.microsoft.com/powershell/2017/11/02/powershell-constrained-language-mode/
This support for application whitelisting has mostly existed in PSCore6, but the primary APIs were stubbed out in CorePSStub.cs because they relied on Windows only DeviceGuard (wldp.dll) and AppLocker (Safer APIs) public APIs. These changes re-implement PowerShell lock down APIs on PSCore6 for Windows platforms only. The AppLocker and DeviceGuard public APIs are currently only implemented in Windows OSes and are not supported on Linux or MacOS platforms.
Tests have also been ported to PSCore6 and run only for Windows platforms.
Create the default PSSession configuration, not tied to a specific PowerShell version.
When Enable-PSRemoting command is run, it creates 2 sessions configurations:
first, the same as it was before with the name containing the current version expressed as: 'PowerShell.$PSVersionTable.GitCommitId'
second with the default name 'PowerShell.6' so that administrators wouldn't have to guess which specific version is installed on the target.
PR addresses the issue: #6470
* Use UTC datetime in Get-Date -UFormat %s
Fix %l output from 0..11 to 1..12
Fix %V using Gregorian calendar
* Use a workaround for ISO 8601 week of year (uformat %V)
Aditya Patwardhan