The tasks that I can think of are:
write access or none share) will cause a new pwsh instance to crash at startup because it cannot access the config file and we don't deal with the IOException.First, run the following code to hold the config file of the current pwsh
$path = "path-to-powershell.config.json"
$mode = "Open"
$access = "Read"
$share = "None"
$file = [System.IO.File]::Open($path, $mode, $access, $share)
Then, start a new instance of the pwsh, and it will crash.
We could make public API to enable developers to work consistently with config files.
It seems currently we read config option step-by-step by demand. I think re-read all config file(s) in one step and cache it is more optimal.
Suggestions:
Configuration priority:
Windows | Unix
-| -
GPO Computer Policy for PowerShell Core | File
GPO Computer Policy for Windows PowerShell | -
File Computer-Wide Version | File Computer-Wide Version
GPO User Policy | ?
File Local Version | File Local Version
File User-Wide (AppData) | File User-Wide
GPO Computer Config | ?
GPO User Config | ?
GPO Computer Policy for Windows PowerShell is not considered when in PS Core as this policy is for a separate product. If we want to honor policy for Windows PowerShell, we should not introduce a policy for PowerShell Core.
@iSazonov @TravisEz13 GPO policy related discussion should happen in a new issue. This issue is for improving the APIs for reading settings from powershell.config.json file. The precedence order of policy related settings is another layer on top of the configuration APIs, not the configuration APIs themselves.
Most helpful comment
@iSazonov @TravisEz13 GPO policy related discussion should happen in a new issue. This issue is for improving the APIs for reading settings from
powershell.config.jsonfile. The precedence order of policy related settings is another layer on top of the configuration APIs, not the configuration APIs themselves.