New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.ResolveTarget() | gci -Recurse
buggy when target contains []
#21568
Comments
The root cause is that - unfortunately - pipeline input to provider cmdlets such as This means that path strings as input - which includes implicitly stringified objects that do not have a Workarounds:
'hi [123].txt' | Select-Object @{ Name='LiteralPath'; Expression={ $_ } } | Get-ChildItem
'hi [123].txt' | Get-ChildItem -LiteralPath { $_ } Note that piping |
Why doesn't the output of Delay-bind script blocks is something I thought up and wanted but didn't know was already supported by the language itself. I thought only cmdlets that explicitly optionally ask for scriptblocks (and thus handle it themselves) accepted it (like |
Are you saying that the earlier cmdlets are looking ahead in the pipeline and modifying their output instead of the later cmdlets accepting and handling different types of inputs? Like gci only accepts strings in, and without gi changing its output, the pipeline is being cast? |
Because, unfortunately, it is only the This problem would go away if these provider-related ETS properties were defined at the type level, which would also speed up things; see the following issue and the one it links to; the discussion around which stalled a long time ago: |
That is an excellent question, but you'll have to ask the original designers; I wish it did.
No, no cmdlet does nor is even capable of looking ahead in the pipeline (at least not without substantial manual effort).
|
4347 needs to be done. This revelation has a lot of implications for basically all of my scripts, I thought the whole point of powershell was that using the pipeline was the safest thing to do; you're piping objects, not just strings. How many other cmdlet-usecases have caveats akin to this, it would be impossible to know.. I feel like the auto casting in the language itself was a bad idea, and it needed to be obvious to the programmer. gci.Resolve() | gci
#Error: Sorry, I only accept strings!
[](gci.Resolve()) | gci
#empty cast declaration, the programmer has opted into auto-casting
gci.Resolve() [|] gci
#some sort of syntax to allow this via the pipeline not only maintaining visual elegance but performance in terms of not blocking the whole generation of the former gci ..alas |
Re potential challenges around
Apart from that, I think the existing pipeline-based argument binding is sufficient except that discovery of which parameters are pipeline-binding and, if so, how is called for; see: |
Prerequisites
Steps to reproduce
cat test.ps1
Expected behavior
Actual behavior
Error details
No response
Environment data
Visuals
No response
The text was updated successfully, but these errors were encountered: