OK, also fühle ich mich wie dieser muss ein Fehler in PowerShell sein, aber ich wollte sehen, wenn ihr denkt, dass das kaputt klingt. Es ist ziemlich einfach zu reproduzieren, aber ich kann sehen, warum es kein besonders häufiger Anwendungsfall ist. Die Schritte, die ich unten gesetzt habe, sind nicht das, was mein Skript getan hat. Ich habe tatsächlich die Größe der Unterordner berechnet - ich habe es nur auf das einfachste mögliche Szenario reduziert, das mein Problem zeigt.
Ich habe dies nur auf der PowerShell 5.0.10240.16384 versucht, könnte aber bald die Möglichkeit haben, es auf einer früheren Version zu testen [ Bearbeiten: Ich habe dies jetzt auf PowerShell 2.0 getestet, und der Fehler tut es nicht erscheint in dieser Version - es funktioniert wie erwartet]. Nur eine kurze Anmerkung - Ich habe gci als Abkürzung für Get-ChildItem verwendet. Wenn Sie das noch nicht wissen, können Sie auch PowerShell eingeben. Aber das Problem besteht unabhängig davon, welchen Alias Sie verwenden.
Erstellen Sie zuerst einen Ordner mit dem Namen Test [123] . Erstellen Sie in diesem Ordner ein paar Dateien. Meine sind caled Test1.txt und Test2.txt . Sie müssen nichts in ihnen haben.
Öffnen Sie als Nächstes eine PowerShell-Sitzung und Set-Location für den übergeordneten Ordner Ihres neuen Ordners Test [123] .
Führen Sie jetzt gci -Filter Test* aus und Sie sollten etwas wie:
Alles gut, oder? Als nächstes probiere gci -Filter Test* | gci . Dies macht die Ausgabe des ersten gci die Eingabe für den nächsten, dh zeigt uns die Kinder jedes Gegenstandes der ersten gci zurück. Das gibt uns folgendes:
Wieder alles gut - genau wie erwartet. Dies sind alle Dateien aus unserem Ordner Test [123] .
Versuchen Sie es jetzt: gci -Filter Test* | gci -Recurse . Alles, was wir geändert haben, ist, dass der zweite Aufruf von gci jetzt rekursiv ist, also sollte er uns alle Dateien einschließlich der Unterordner anzeigen. Wir haben keine Unterordner, also erwarten wir die gleichen Ergebnisse, oder?
Falsch. Wir bekommen überhaupt keine Ausgabe. Es scheint sehr merkwürdig, dass alles, was wir gemacht haben, -Recurse hinzugefügt wurde und wir jetzt unterschiedliche Ausgaben bekommen. Ich denke, das Hinzufügen von -Recurse sollte nie weniger ausgeben, sondern immer mehr.
Hier ist das nächste komische Ding. Versuchen Sie nun gci -Filter Test* | gci -Recurse -Name . Dies ist das gleiche wie zuvor, außer dass der Parameter -Name hinzugefügt wurde. Das heißt einfach, dass wir die gleiche Ausgabe wollen, außer wir wollen nur die Dateinamen und nicht die vollständigen Informationen über jedes Element. Also erwarten wir wahrscheinlich nichts zurück. Aber das bekommen wir nicht, wir bekommen das:
Das hat bekommen gebrochen zu sein, oder? Erstens sollte -Recurse niemals die Menge der Ausgabe reduzieren, und zweitens, die Ausgabe in einem anderen Format zu verlangen, sollte die Menge der Ausgabe, die wir bekommen, nicht ändern.
Dies tritt nur auf, wenn im Namen des Ordners eckige Klammern stehen. Wenn Sie einen anderen Ordner erstellen, einfach Test genannt, und alle oben genannten Befehle erneut ausführen, werden Sie immer die Dateien aus dem Ordner Test sehen.
Meine Recherche führte mich zum Parameter -LiteralPath ; Wenn Sie jedoch den obigen Befehl als gci -Filter Test* | foreach { gci -Recurse -LiteralPath $_ } umschreiben, um diesen Parameter zu verwenden, gibt er immer noch keine Ausgabe zurück, und durch das Hinzufügen des Parameters -Name werden die Dateien erneut gestartet.
Ich habe es geschafft, einen Workaround dafür zu machen, indem ich den -Name -Parameter benutze und ihn dann mit dem Pfad des gesuchten Ordners kombiniere und dann in Get-Item übergebe, aber das hat den Code länger gemacht und hässlicher als es sein muss.
Also meine Frage ist, habe ich einen Fehler gemacht oder etwas falsch verstanden? Oder ist das ein Fehler, den ich melden sollte?
Es sieht so aus, als hätte ein Fehler hier oder ein sehr ähnliches Problem gemeldet.
Tags und Links powershell get-childitem