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 ('\').
This action is completely valid on both Windows and Linux (and OS X)
operating systems; tested with `mklink` and `ln -s` respectively.
Note that targets for hard links must exist, thus we check specifically
for symbolic links.
Both the path globber in session state and the `New-Item` implementation
needed to be fixed to allow the target not to exist.
Resolves#801.
Also enable symbolic link tests on Windows.
Andrew Schwartzmeyer