All CLA requirements met.

@renehernandez Thanks for your contribution!

I added 'Fix #5544' to link the issue and auto close it after we merge.

The public API should be approved by PowerShell Committee.

@PowerShell/powershell-committee reviewed this and is ok with adding PathSeparator

This PR has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed if no further activity occurs within 10 days.
Thank you for your contributions.
Community members are welcome to grab these works.

@daxian-dbw Is this going to be merged at all? The changes are pretty small and they shouldn't be to hard to review.

Or is there anything left that should be addressed??

@renehernandez Sorry for having this PR slip off my radar. I will do the review later today.

@renehernandez When you are addressing my comments, can you please add the [Feature] tag to the last commit's message? I would like the CI to run all feature tests for this PR.

@renehernandez I think we need to implement the PathSeparator property in a different way.
Here is my suggestion:
Add a public virtual get-only property PathSeparators in CmdletProvider. The default implementation can be this:

public virtual ReadOnlyCollection<string> PathSeparators => Utils.EmptyReadOnlyCollection<string>();

Then, add a public-getter-private-setter property PathSeparators in ProviderInfo. The default implementation can be this:

public ReadOnlyCollection<string> PathSeparators { get; private set; }

Then, in the ProviderInfo.CreateInstance, after casting providerInstance to CmdletProvider, we set the PathSeparators property in the Provider instance:

Provider.CmdletProvider result = providerInstance as Provider.CmdletProvider;
PathSeparators = result.PathSeparators;

Then, in each provider implementation, override that property to provide the supported separators.

@daxian-dbw Are you suggesting a rename as part of the change? Should the property be plural, i.e. PathSeparators?

PS:28> [System.IO.Path] | gm -Static
...
AltDirectorySeparatorChar   Property   static char AltDirectorySeparatorChar {get;}
DirectorySeparatorChar      Property   static char DirectorySeparatorChar {get;}
InvalidPathChars            Property   static char[] InvalidPathChars {get;}
PathSeparator               Property   static char PathSeparator {get;}
VolumeSeparatorChar         Property   static char VolumeSeparatorChar {get;}

@renehernandez If we look at how System.IO.Path name those properties, I think plural would be better as we return a collection. But let me check with the committee before we move forward.

@PowerShell/powershell-committee Need your another review on three items:

1. Since the new property PathSeparator returns a collection (ReadOnlyCollection), shall we rename it to PathSeparators (plural)?
2. Do we allow a string of more than 2 characters used as a path separator in PowerShell providers? If not, maybe make the property return ReadOnlyCollection<char>?
3. Is it OK to add a public virtual get-only property PathSeparators in the public abstract class CmdletProvider? Implementation looks like this:

public virtual ReadOnlyCollection<string> PathSeparators => Utils.EmptyReadOnlyCollection<string>();

Here's my 2¢:

• Re 1: I know it's late in the game, but, seeing the CoreFx approach of providing DirectorySeparatorChar and AltDirectorySeparatorChar separately, I wonder if we should similarly provide two scalar properties, PathSeparator and AltPathSeparator - given that my guess is that users will typically want the official separator, even though there may be an alternative (which, as far as native data stores go, really only applies to the filesystem on Windows).

  • As an aside: \ currently de facto works on Unix too, but shouldn't, because \ is a legal filename character - see On Unix, PowerShell will not find files with backslashes in their names #3666

• Re 2: My vote is for string rather than char, for the following reasons:

  • Given that the property will (also) be consumed from PowerShell code, there is no advantage to using char over string, given that char is not a first-class type in PowerShell code, where even single characters are by default represented as strings.
  • It leaves the door open for providers with multi-character separators - though that is admittedly not very likely to happen.

@SteveL-MSFT: Please see #9244

today the registry provider also accepts and normalizes / and . But we agreed that's not right and should be corrected in future.

Have we a tracking issue?

The issue tracking registry provider is #5536

@renehernandez Thank you again for your contribution and patience!