'Split-Path "/" -Leaf' returns empty string instead of "/" on Ubuntu1804/Linux/Wsl

Steps to reproduce

On WSL Ubuntu 1804 or probably any other linux distro

Split-Path "/" -Leaf

Expected behavior

return a slash

/

Actual behavior

returns an empty string

Environment data

Name                           Value
----                           -----
PSVersion                      7.1.0
PSEdition                      Core
GitCommitId                    7.1.0
OS                             Linux 4.19.128-microsoft-standard #1 SMP Tue Jun 23 12:58:10 UTC 2020
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[SeidChr]

Don’t get me wrong. I agree to you on how this should be handled. I was just giving a different point of view. Doesn’t mean it was the proposed way to fix it.

[mklement0]

Just a terminology quibble:

paths that start with a separator are just an indication for them to be absolute

• On Window, they are rooted ([IO.Path]::IsPathRooted() returns $true), but not absolute ([IO.Path]::IsPathFullyQualified() returns $false)

• On Unix, they are both rooted and absolute.

Using Join-Path and Split-Path is good practice: Join-Path avoids the C:\\foo problem (though Split-Path doesn’t correct it).

However, another reason not to treat '' as the root directory is that Join-Path '' foo simply fails.

Also, as stated, if you made Split-Path /foo -Parent return '' (even though on Unix it currently does, but that’s a variation of the bug at hand), you couldn’t distinguish it from Split-Path foo -Parent - at least not without introducing a serious breaking change (such as to return . in the latter case).

Similarly, for consistency, you’d have to then allow Get-ChildItem '' to list the root directory, whereas it currently lists the current one.

In short: It is generally problematic to refer to a specific something (the root dir.) with nothing (the empty string), and using \/ / as the name of the root dir. is the best compromise.

As for how Split-Path C:\ -<switch> should be handled:

• Split-Path C:\ -Leaf on Windows and Split-Path / -Leaf on Unix should return the name of the root dir, and therefore \ an /, respectively

  • On Windows, it currently returns C:\, which strikes me as incorrect - but fixing it would be a breaking change.

  • On Unix - which is the bug at hand - it returns '' (which by the (to me ill-advised) logic of considering '' the root dir.'s name would actually be correct).

• Split-Path C:\ -Parent on Windows and Split-Path / -Parent on Unix are tricky:

  • The root directory by definition has no parent, and [IO.Path]::GetDirectoryName() indicates this by returning $null - as opposed to the '' returned for something like [IO.Path]::GetDirectoryName('foo')

  • This is too subtle a distinction for PowerShell, where [string] values usually do not contain$null:

    • On Windows , Split-Path C:\ -Parent currently returns '' - changing that would be a breaking change.

    • On Unix, Split-Path / -Parent is currently broken, as you reported in #14392, which is a duplicate of #10092; for consistency, absent a breaking change, it should also return ''.

    • The upshot is that if you call Split-Path -Parent $path on an unknown path $path and get '' back, you’ll need further investigation ([IO.Path]::IsPathRooted()) to infer whether $path refers to a root dir. (with or without a drive spec.) or is a mere file or directory name such as foo.

      • Note that Split-Path -IsAbsolute isn’t suitable for this distinction, because Split-Path \ -IsAbsolute is $false on Windows.
      • As an aside: It is Test-Path that should have this switch - it never made sense on Split-Path. Better yet, Test-Path should support an enumeration-based -PathForm / -Form parameter that allows testing for specific path forms (absolute, relative, rooted, UNC) - see #14402