This seemed to me an error and I and was on the point of raising it as a bug on the Powershell github repo:
PS> "\this".Split( [char]'\', [StringSplitOptions]::RemoveEmptyEntries).Length # >> 2
Presumably it is because [StringSplitOptions]::RemoveEmptyEntries is coerced to a [char] and so the line is parsed as:
PS> "\this".Split( ([char]'\', [StringSplitOptions]::RemoveEmptyEntries) ).Length
Instead of as
PS> \this".Split( (,[char]'\'), [StringSplitOptions]::RemoveEmptyEntries).Length
If the first parameter is a string not a character then it works as expected:
PS> "\this".Split( '\', [StringSplitOptions]::RemoveEmptyEntries).Length # >> 1
But the really unfortunate case is :
PS> "\this".Split( [System.IO.Path]::DirectorySeparatorChar, [StringSplitOptions]::RemoveEmptyEntries).Length # >> 2
which results in
PS> "\this".Split( [System.IO.Path]::DirectorySeparatorChar, [StringSplitOptions]::RemoveEmptyEntries).[0] # >> $null # instead of # >> "this"
It turns out that it's fixed in Powershell 6 Beta; or to be more precise, it doesn't happen in PowerShell 6. What changed is that the underlying .Net framework has added new overloads to String.Split():
string[] Split(char separator, System.StringSplitOptions options) string[] Split(char separator, int count, System.StringSplitOptions options) string[] Split(string separator, System.StringSplitOptions options) string[] Split(string separator, int count, System.StringSplitOptions options)
Whereas PowerShell 5 only has these overloads available:
string[] Split(Params char[] separator) string[] Split(char[] separator, int count) string[] Split(char[] separator, System.StringSplitOptions options) string[] Split(char[] separator, int count, System.StringSplitOptions options) string[] Split(string[] separator, System.StringSplitOptions options) string[] Split(string[] separator, int count, System.StringSplitOptions options)
And so the best-match overload that PowerShell 6 chooses is different to PowerShell 5's best match.