Repository navigation
Strange behavior with Get-ChildItem #5269
Description
Activity
It seems that the behavior is that if you have a wildcard, then the recursion is applied to the results of that wildcard expansion. Assume a folder structure like:
testPS d1 d2gci testPS\*returnsd1as expected
now, if you usegci testPS\* -recurse, the-recurseis applied tod1, nottestPSdue to the wildcard andd2is returned.I agree that the behavior may not seem intuitive, but it does seem (somewhat) logical. I'd be concerned that a change here would not be a breaking change worth making. Perhaps we should just update the documentation?
Perhaps we should just update the documentation?
Yes.
- According to the help file 'about_Wildcards' :
Wildcard Description Example Match No match -------- ------------------ -------- ----------------- -------- * Matches zero or a* A, ag, Apple banana more charactersAre these statements equivalent (with my first exemple) ?
$Path='C:\temp' get-childitem -path "$Path\TestPS\*" -Recurse get-childitem -path "$Path\TestPS" -Recurse
- According to the help file 'FileSytem' (DYNAMIC PARAMETERS) :
-File <System.Management.Automation.SwitchParameter> Gets files. The File parameter was introduced in Windows PowerShell 3.0. To get only files, use the File parameter and omit the Directory parameter. To exclude files, use the Directory parameter and omit the File parameter, or use the Attributes parameter.Are these statements equivalent (with my first exemple) ?
$Path='C:\temp' get-childitem -path "$Path\TestPS\*" -File -Recurse get-childitem -path "$Path\TestPS\*" -Recurse |Where {-not $_.PSisContainer}
If for this last example these statements are equivalent, in my case the resultat is different.
- added this to the milestone
on Nov 3, 2017 I missed the details about
Fileand agree that it's broken.- assigned and unassigned
on Nov 3, 2017 Steve Lee (@SteveL-MSFT) this fix do not should be backported to Windows PowerShell 5.1 ?
Laurent Dardenne (@LaurentDardenne) the concern would be that this is a breaking change so at this time not considered to be ported to 5.1
OK, thanks.
How to find the list of these bugs / difference ?
Can the addition of a label be considered here or should we duplicate this issue on Uservoice?Laurent Dardenne (@LaurentDardenne) the label indicates we're considering backporting it to Windows PowerShell 5.1. At the time of actual port, we'll determine if it's too risky to port due to risk of regression (since the PSCore6 code base has now deviated quite a bit from the Windows PowerShell code base). Perhaps I'll create a new label
Ported-WindowsPowerShell51to indicate PRs that have been ported.Steve Lee (@SteveL-MSFT)
There is the label '_Breaking-Chang_e' which is very useful when porting code v5.n to v6.n
A 'Ported-WindowsPowerShell51' label can be useful information.This fix does not have the 'Breaking-Change' label, but in the case of a 6.n code port, (based on this corrected behavior) to-> 5.n, how do I find these cases?
A 'NotPorted-WindowsPowerShell51' label ? :-)
Or a note inside the Changelog.md file ?It is information intended for the users and not for the monitoring of the project.
Laurent Dardenne (@LaurentDardenne) this issue should have had the
Breaking-Changelabel, was just missed. We usually have theBreaking changesat the top of the ChangeLog. We have a work item to have better documentation on porting scripts/modules from 5.1 to 6.Reacted by Laurent Dardenne
Steps to reproduce
Expected behavior
The following calls must return existing files or directories :
Actual behavior
When the 'root' of the search ('C:\Temp\TestPS') is empty, the search do not return all entries :
Environment data
Same problem with For Windows PowerShell v 5.1.14409.1012 :