Import-Csv fails to bind Get-ChildItem output to its -LiteralPath parameter via the pipeline

^{Related: #4472.}

The -LiteralPath parameter, via its -PSPath alias, is normally used to bind to objects piped from Get-ChildItem / Get-Item, such as with the Get-Content cmdlet.

Import-Csv currently fails to establish this binding.

Steps to reproduce

'file1.csv', 'file2.csv' | % { $null > $_ }
Get-ChildItem file*.csv | Import-Csv

Expected behavior

Binding of the [System.IO.FileInfo] instances via their .PSPath property to -LiteralPath, and therefore no output (null collection), given that both files are empty.

Actual behavior

The following statement-terminating error is reported:

Import-Csv : You must specify either the -Path or -LiteralPath parameters, but not both.

Environment data

PowerShell Core v6.0.0-beta.4 on macOS 10.12.5
PowerShell Core v6.0.0-beta.4 on Ubuntu 16.04.2 LTS
PowerShell Core v6.0.0-beta.4 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)
Windows PowerShell v5.1.15063.413 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)

[markekraus]

@Lipkau pointed me to this issue.

The problem appears to be with the way in which the parameter sets are done for this cmdlet. There are 2 parameter sets: One for Delimiter and another for Culture. Each set accepts both -Path and -LiteralPath and then performs a runtime check for the presence of both.

[mklement0]

@SteveL-MSFT: Thanks for the feedback.

The 1st hit when I searched Stack Overflow for [powershell] import-csv get-childitem was a question from 2013 relating to this very bug: https://stackoverflow.com/q/18254718/45375

I haven’t sifted through the remaining hits, but anecdotally I can tell you I’ve seen people run into the problem repeatedly.

Either way, it should be a simple bug to resolve, and given that the current behavior is simply broken, there should be no backward-compatibility concerns.