Powershell: Split-Path -Parent / currently broken on Unix

[mklement0]

Steps to reproduce

Split-Path -Parent /

Expected behavior

The empty string (current behavior on Windows), but, ideally, / - see #4131

Actual behavior

An error occurs.

Split-Path : Cannot process argument because the value of argument "path" is not valid. Change the value of the "path" argument and run the operation again.

Environment data

PowerShell Core v6.0.0-beta.3 on macOS 10.12.5
PowerShell Core v6.0.0-beta.3 on Ubuntu 16.04.1 LTS

[mklement0]

@SteveL-MSFT: A general question re labeling:

Given that macOS is affected too, is label OS-Linux sufficient?

When I refer to "Unix" in my issues, I mean both macOS and Linux (all Unix-based platforms).

Is there a label that covers both?

[thorstenkampe]

Not just -Path / -Parent is broken but also -Leaf: Split-Path -Path / -Leaf returns an empty string instead of /.

[SteveL-MSFT]

So on Windows, split-path c:\ -parent returns empty string and split-path c:\ -leaf returns c:\. If we want symmetry, then on Unix-based systems, split-path / -parent would be empty string and split-path / -leaf should be /, right?

[mklement0]

That Split-Path -Leaf / should return / indeed does make sense, and is in line with basename /, as per POSIX.

As for Windows: Split-Path -Leaf c:\ looks broken.
The _drive spec_ should definitely not be part of the return value, given that the intent is to return a filesystem item's _name_, so, analogously, \ would seem more appropriate.

(There will forever be confusion stemming from the root directory having no name of its own and instead being identified by the _path separator_.)

[thorstenkampe]

@SteveL-MSFT If you want consistency: yes. But please be aware that other implementations handle it differently or exact oppositely:

# Linux GNU coreutils return `/` for parent and leaf
pwsh> dirname /
/
pwsh> basename /
/

# Python returns '/' with or without drive for parent and empty string for leaf
>>> pathlib.Path('F:\\').parent
WindowsPath('F:/')
>>> pathlib.Path('F:\\').name
''

>>> pathlib.Path('/').parent
PosixPath('/')
>>> pathlib.Path('/').name
''

[mklement0]

@thorstenkampe:

(I got confused in my previous post (dirname vs. basename) - now corrected.)

It makes more sense for PowerShell to follow the example of other _shells_.

Your Unix-utility-based examples - dirname / (equivalent of Split-Path [-Parent] /) and basename / (equivalent of Split-Path -Leaf /) go beyond just _implementations_ - such as the GNU coreutil implementations you reference - they are actually codified in the POSIX _standard_.

So, yes, from that perspective, _both_:

• Split-Path -Parent / a.k.a. Split-Path /

• and Split-Path -Leaf /

  should return /.

[thorstenkampe]

@mklement0 I agree.

But please acknowledge that other cross platform high level programming languages like Python have chosen a different route. Python's pathlib is a recent implementation So it's not like that was a rookie mistake. They know what they were doing. Would be interesting to find their reasoning for doing so.

[SteveL-MSFT]

I think it's fine to not have symmetry for the sake of symmetry. On Unix, if the expectation is that the -Leaf and -Parent of / is /, then I think that would be ok and just documented. On Windows, I don't think we'll change it as it would be a breaking change w/o clear benefit to warrant the change. Will have @PowerShell/powershell-committee review.

[SteveL-MSFT]

@PowerShell/powershell-committee reviewed this. Expectation is that scripts using the current Windows PowerShell behavior to parse a file path would need to special case Unix if we have non-symmetric behavior. For example:

$path = "/"; while ($path -ne "") { $path = split-path -parent $path;$path }

This loops forever since the ending state is never hit. To support the same scripts working on Windows and Unix, we need to fix the behavior on Unix so that:

split-path -leaf / => returns /
split-path -parent / => returns ""