Our private implementation of FailFast was likely introduced
when each individual application needed it's own code to
get Watson reports. The CLR takes care of this for us now,
so we don't need our implementation.
Our method CheckForSevereException was also introduced in
the early days of the CLR - the exceptions it was checking
for aren't actually raised the CLR anymore, they just FailFast.
I removed them as there is a tiny bit of overhead (in code size)
and also in the generated code, e.g. dynamic sites called the method.
Resolving #2570.
Ignore drive paths in the check. If the input is a drive path,
then "\" is passed as the path to GetDriveQualifiedPath with drive info.
Since, the path here starts with "\", treatAsRelative is set to false
which prevents further formatting of this path.
The check is only valid for PSDrives with root path equals to UNC paths or the paths
in unix.
Resolving #2206
Set-Content fails to create a file for PSDrive path, if the path root
begins with defaultPathSeperatorString (ex: UNC path and paths in Single
rooted filesystems like Unix)
This is verified to work "correctly" on Linux in that it gets the
`perror` for the last set value of errno in native code.
No extra mapping or handling needs to be done on our part.
Keeping the strerror_r implementation in the history for the valuable
implementation of config.h.in in the library.
Also includes these bugfixes:
- WSManConfigProvider.GetHelpMaml: Tried to load XML from
MemoryStream that was created from file name string. Use XmlReader
instead.
- WSManConfigProvider.GetHelpMaml: Use Path.Combine instead of
platform-specific directory separator character.
- WSManConfigProvider.GetHelpMaml: CmdletHelpPath MAML XML element
attribute `ID` name casing seems inconsistent with other help.xml
files. XPath 1.0 does not support case-insensitive expressions,
use both `id` and `ID` in query.
- Add Pester test to verify that Get-Help shows provider-specific help.
Fixes#2088
Use 'Path.PathSeparator' instead of ';' to separate paths, so that it uses ';' on windows and ':' on unix.
Also refactor some code as part of the change.
Mostly using R# to automatically refactor, with some manual
fixups where it wouldn't work automatically (e.g. xml comments
on fields) or some it seemed to miss.
Some minor code reformatting was also done on properties near
other stuff I was manually inspecting.
I (Jason Shirk) ran https://github.com/dotnet/codeformatter with the default rules, basically:
codeformatter /nocopyright "/c:DEBUG,UNIX,CORECLR" @files.rsp
This caused a few problems building, which were fixed up manually.
Notable changes:
`this.` is removed unless needed to disambiguate.
private instance fields are renamed to have a `_` prefix.
private static fields are renamed to have a `s_` prefix.
I left some projects alone (like PackageManagement) and also left some generated code alone.
These currently fail at runtime on Nano, and will continue to do so. But
this implements these much needed cmdlets for Open PowerShell.
If there is a way to determine that PowerShell is being run on the Nano
OS at runtime, then we could instead throw a platform unsupported
exception, but this cannot be based on the target compilation framework,
as .NET Core is shared for both Nano and Windows.
These comparisons did not need to be changed as the input path is not
modified. The normalized relate path created from the stack (if this
code path is taken) is created with the correct path separators.
Assuming the path may not be normalized, to make PowerShell slash
agnostic in a filesystem whose "drive" is a '/' and a 'C:\', we need to
compare to both '/' and '\' for users of PowerShell's alternate path
separator on Linux ('\').
Dongbo Wang