Resolving #3242
At this point, user account is created even if user attributes assignment
(like setting password) fails. The cmdlet throws a
non-terminating error but ends up creating the user. This behavior is
confusing. As per the changes, the localuser account will be rolled back
in case of failure in user attributes assignment.
Two updates with this PR:
- reclassified automounted drives tests to be 'Feature' instead of 'CI' because this is more accurate;
- fixed failures in tests setup caused by "subst.exe" native utility having problems running as child process of powershell process tree run under "runas.exe /trustlevel:0x20000" (in Start-UnelevatedProcess in build.psm1).
Get-Content /etc/os-release returns an array of strings, which get feeded to ConvertFrom-StringData. Therefore, $LinuxInfo is actually an array of Hashtable instances before this change. Property access on $LinuxInfo like $LinuxInfo.ID happens to work because powershell supports accessing a property or calling a method on a collection of object, but it's inefficient.
After this fix, $LinuxInfo will be a Hashtable, and it's efficient to access its members.
Adds ntml over spnego for authentication between windows and centos7.3
and ubuntu 16.04.
Fixes a number of problems that stopped connection to
exchange/office365.
* adds parameter sets to web cmdlets to allow for standard and non-standard method verbs
* add CoreCLI implementation
* Adds CM alias and notnullempty for CustomMethod parameter
* Add tests for Invoke-[WebRequest|RestMethod] CustomMethod parameter
* Fix webcmdlet tests - incorrect parameter name
XDG profile directory creation can fail for accounts that do not have home directories.
The module analysis was trying to persist it's cache in an XDG profile directory.
The cache is less critical than it once was, so it's reasonable to not cache if there is no good place to do so.
Fixes#3011
This commit removes the external dependencies of the AppImage generation script by instead
downloading them from a known (and owned by Microsoft) location:
psgithub.file.core.windows.net.
Changed hard coded Windows directory separator and resolved path so the slashes are correct.
Throw if resolving file path returns more than one result
Fixes#2610
These changes provide the ability to debug remote running scripts started with the Invoke-Command cmdlet. The design is event based and provides new public events that allow subscribers to be notified when an Invoke-Command remote session is ready for debugging. Since Invoke-Command allows running scripts on multiple targets at once (fan-out) the notification event is raised for each remote session as it becomes ready for debugging. The subscriber to these events will be a script debugger implementation (such as PowerShell console, ISE, or VSCode) and will handle all debugging details such as simultaneously debugging multiple remote sessions at once in separate windows.
But these changes also include an internal implementation which is used by default if host debuggers don't want to handle the debugging details. This internal implementation is what PowerShell console, ISE uses so they can have this new behavior without having to modify their debugger implementations. The internal implementation serializes each remote session of Invoke-Command so that they can be debugged one at a time. The remote session debugger is "pushed" onto the internal debugger stack so that debugging transitions to the remote session. Existing debugging commands work so that the "quit" debugging command will stop the current remote session script from running and allow the next remote session to be debugged. Similarly the "continue" debugging command allows the script to continue running outside step mode and again go to the next remote session for debugging. The "stepout" debugging command steps out of all Invoke-Command remote sessions and lets the script continue to run for each remote session in parallel as they are normally run.
The purpose of Invoke-Command step-in remote debugging is allow seamless debugging of a local script that calls Invoke-Command on remote targets. But there is also a new Invoke-Command "-RemoteDebug" parameter that lets you Invoke-Command on the command line and have it drop directly into the debugger.
An example from the PowerShell command line looks like this:
```
PS C:\> C:\TestICM.ps1
Entering debug mode. Use h or ? for help.
Hit Command breakpoint on 'Invoke-Command'
At C:\TestICM.ps1:2 char:1
+ Invoke-Command -cn $computerName,paulhig-3 -File c:\LinuxScript.ps1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[DBG]: PS C:\>> list
1: $computerName = "localhost"
2:* Invoke-Command -cn $computerName,paulhig-3 -File c:\LinuxScript.ps1
3: "Test Complete!"
[DBG]: PS C:\>> stepin
At line:1 char:1
+ Write-Output "Running script on Linux!"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[paulhig-3]:[DBG]: [Process:14072]: [Runspace5]: PS C:\Users\paulhi\Documents>
```
Notice that the debugger "stepin" command transitioned from local script debugging to debugging the remote session on computer "paulhig-3", as can be seen by the change in the debugger prompt.
You can also do this from the command line to drop directly into the debugger
```
Invoke-Command -cn localhost -Script $scriptblock -RemoteDebug
```
These changes also remove an old behavior that was incompatible with this new step-in feature. Previously if a remote session running script hit a break point it would stop in the debugger and go to the "disconnected session" state. This was to allow the user to reconnect using Enter-PSSession and then interactively debug the remote session script. This behavior has been removed and now the user needs to attach a debugger using the newer Debug-Runspace cmdlet.
* Prettier formatting for ConvertTo-Json output. #2736
This change standardizes JSON output to example given, as well as
codemaid and online lint tools.
Sample object used for testing:
@{
foo = @{
first = 'a'
second = 'bbbbbbbb'
}
barbarbarbar = @{
first = 'a'
second = 'bbbbbbbb'
NestedArray = @(
'Test3'
'Test4'
'Test5'
3
4
)
NestedObject = @{
MoreObject = 'AnotherObject'
TestBool = $true
}
}
array = @(
'Thing1'
'Thing2'
)
dan = 15
} | ConvertTo-Json
* Updated CoreCLR implementation to use NewtonSoft Indented Formatting
I did not change the FullCLR behavior, I was not sure if you meant to
revert my changes or to leave it as is in the current pull request.
* Added tests that validate pretty Json output.
Not sure if there is a better thought on how to implement these. The
first two fail against current master, but succeed once this PR is
applied. Third test is successful prior and post this PR.
* Moved tests and removed extraneous file.
Moved pretty/compressed json tests from standalone file into the
existing ConvertTo-Json test file.
* Updated tests for cross-platform support
* Implement -version parameter in console host (address part of https://github.com/PowerShell/PowerShell/issues/1084)
This does not support providing a specific version to run, but
like most other *nix commands, -version will now return the version
of the PowerShell Engine. 'powershell' is prepended to the output to
match other *nix commands. We are using gitcommitid which includes more
info about the build.
* Changed broken link to a working blog post
"run-ps" isn't a linkable document, so I changed the "Running PowerShell Scripts Is as Easy as 1-2-3" to link to an external article on Windows IT Pro with the same name.
* Add ShouldProcess to New-FileCatalog and Test-FileCatalog
Close#3068
Add support `-WhatIf` and `-Confirm` to `New-FileCatalog` and add a
test.
`Test-FileCatalog` has a common code base with `New-FileCatalog` so it
automatically get the same. I believe that adding a separate test in
this case doesn't make sense.
* Fiz after code review
Remove _ShouldProcess
Add var in test
