12
Powershell for Windows - Get-ChildItem mit Filter
Hallo
Ich habe ein PS Skript das funktioniert.
Der Abschnitt um den es geht sieht so aus:
Jetzt soll die Variable "xlsxFiles" weitere Dateitypen beinhalten:
-xlsx
-xlsm
-xls
Diese drei Versuche schlugen fehl. D.h. Die Meldung "Loop activ" wird nie angezeigt.
$xlsxFiles = Get-ChildItem -Path $sourceDirectory -Include *.xlsx,*.xlsm,*.-xls
$xlsxFiles = Get-ChildItem -Path $sourceDirectory -Filter "*.xlsx,*.xlsm,*.-xls"
$xlsxFiles = Get-ChildItem -Path $sourceDirectory Where-Object { $_.Name -match '*.xlsx|*.xlsm' }
Alle Lösungen die ich sonst finde nutzen "dir" bzw. "ls" anstatt "gci".
Zur Unterstützung meiner Lernkurve würde ich gerne das Skript in reinem PS for Windows schreiben.
Der Ansatz mit "Set-Location" in das SourceDirectory zu wechseln und danach "gci *.xsl, *.xslt" abzusetzen ist mir nicht elegant genug. Da gibt es doch sicher eine besser Lösung als im Laufwerk herum zu springen, nur weil ich nach bestimmten Dateitypen suche.
Danke im Voraus für einen Hinweis
Beste Grüsse
Ich habe ein PS Skript das funktioniert.
Der Abschnitt um den es geht sieht so aus:
$xlsxFiles = Get-ChildItem -Path $sourceDirectory -Filter "*.xlsx"
foreach ($xlsxFiles in $xlsxFiless) {
# Get the file name without extension
write.host Loop activJetzt soll die Variable "xlsxFiles" weitere Dateitypen beinhalten:
-xlsx
-xlsm
-xls
Diese drei Versuche schlugen fehl. D.h. Die Meldung "Loop activ" wird nie angezeigt.
$xlsxFiles = Get-ChildItem -Path $sourceDirectory -Include *.xlsx,*.xlsm,*.-xls
$xlsxFiles = Get-ChildItem -Path $sourceDirectory -Filter "*.xlsx,*.xlsm,*.-xls"
$xlsxFiles = Get-ChildItem -Path $sourceDirectory Where-Object { $_.Name -match '*.xlsx|*.xlsm' }
Alle Lösungen die ich sonst finde nutzen "dir" bzw. "ls" anstatt "gci".
Zur Unterstützung meiner Lernkurve würde ich gerne das Skript in reinem PS for Windows schreiben.
Der Ansatz mit "Set-Location" in das SourceDirectory zu wechseln und danach "gci *.xsl, *.xslt" abzusetzen ist mir nicht elegant genug. Da gibt es doch sicher eine besser Lösung als im Laufwerk herum zu springen, nur weil ich nach bestimmten Dateitypen suche.
Danke im Voraus für einen Hinweis
Beste Grüsse
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 71408731558
Url: https://administrator.de/contentid/71408731558
Ausgedruckt am: 21.11.2024 um 14:11 Uhr
12 Kommentare
Neuester Kommentar
Hi
Die richtige Syntax wäre...
...weil Include ein String-Array erwartet. Das kannst du auch hier nachlesen.
Die richtige Syntax wäre...
Get-Childitem -Path "dein Pfad" -Include "*.xls", "*.xlsx", "*.xlsm" ...weil Include ein String-Array erwartet. Das kannst du auch hier nachlesen.
Zitat von @mayho33:
Hi
Die richtige Syntax wäre...
...weil Include ein String-Array erwartet. Das kannst du auch hier nachlesen.
Hi
Die richtige Syntax wäre...
Get-Childitem -Path "dein Pfad" -Include "*.xls", "*.xlsx", "*.xlsm" ...weil Include ein String-Array erwartet. Das kannst du auch hier nachlesen.
ACHTUNG! Hier fehlt etwas ganz entscheidendes! Man muss bei Verwendung von -Include beachten das es nur richtig funktioniert wenn man entweder den Schalter -recurse verwendet oder wenn man damit nicht rekursiv suchen möchte im -Path am Ende ein Sternchen setzen muss, den sonst ist das Ergebnis leer! Eine der Eigenheiten von Get-ChildItem
Get-Childitem -Path "d:\pfad\*" -Include "*.xls", "*.xlsx", "*.xlsm" -File Man kann natürlich jederzeit auch mit Where-Object arbeiten aber das ist dann natürlich erheblich langsamer weil erst im Nachhinein gefiltert wird statt mit dem Dateisystemfilter
Get-Childitem -Path "d:\pfad" -File | where-object {$_.Extension -in ".xlsm",".xlsx",".xls"}
# oder mit Regex
Get-Childitem -Path "d:\pfad" -File | where-object {$_.Extension -match "\.xls[xm]?$"} Alle Lösungen die ich sonst finde nutzen "dir" bzw. "ls" anstatt "gci".
Das sind alles die selben Befehle und nur Aliase für Get-ChildItemGruß sid
1
...weil Include ein String-Array erwartet. Das kannst du auch hier nachlesen.
Guten Morgen
Danke für den Tipp. Gefunden:
Specifies an array of one or more string patterns to be matched as the cmdlet gets child items.
Wieder einmal RTFM
Beste Grüsse
Zitat von @PeterGyger:
Passiert mir auch immer wieder mal, aber mittlerweile einfach viel weniger....weil Include ein String-Array erwartet. Das kannst du auch hier nachlesen.
Wieder einmal RTFM Außerdem ist das Manual zeigen doch immer wieder ein guter Tipp...
1
Hallo Sid
Danke für die umfassende Auskunft!
Aussage 1:
TopDown:
Wenn ich Gci verwende, um nur bestimmte Dateientypen im Verzeichnis zu sehen, habe ich
A: 2 Parameter zur Auswahl
A1 "inlcude"
A2 "filter"
B: Pipen und über Where Funkton gehen
Korrekt?
Aussage 2:
Diesen Abschnitt habe ich jetzt drei Mal gelesen und denke noch immer darüber nach...
A:
Es soll nur das lokale Verzeichnis überprüft werden. Also ist "-recurse" nicht notwendig.
Natürlich funktioniert es damit. Soeben getestet.
$xlsxFiles = Get-ChildItem -Path $sourceDirectory -recurse -Include *.xlsx,*.xlsm,*.-xls
SS64.COM ist für mich leichter zu verstehen, als die MS Manuals:
This parameter is only effective when the command includes -Recurse to match files
or if the string matches the contents of a directory.
B
Das verstehe ich nicht. Die Aussage dieses Satzes wäre in einem Beispiel:
Sollte nicht gehen: Get-ChildItem -Path "X:\000 Selektion\99 Ablage" -Include *.xlsx,*.xlsm,*.pdf
Sollte gehen: Get-ChildItem -Path "X:\000 Selektion\99 Ablage*" -Include *.xlsx,*.xlsm,*.pdf
Ein Test ergibt, dass beide Befehle kein Resultat anzeigen. Könntest Du rein aus Neugierde, den Sachverhalt mit dem Stern in einfacher Sprache verdeutlichen?
Aussage 3:
Where-object habe ich mit der Syntax geschludert. Mir selbst ein Bein gestellt. Deine Variante funktioniert natürlich:
Aussage 4:
GCI und Aliase. Der Sachverhalt ist mir bekannt. Viele Lösungen von Praktikern verwenden die CMD Befehle.
Aus Zeitgründen kann ich dazu weder Argumente noch Beispiele liefern.
Last but not least:
Du erwähnst "-Filter" nicht. Zitat von SS64.com:
A filesystem -filter will use the old Win32/DOS syntax - see the wildcards page for details.
Filters are slightly more efficient than -include/-exclude, because the provider
applies the filter when retrieving the objects, rather than having
PowerShell filter the objects after they are retrieved.
Mit -Filter lässt sich nur ein Muster angeben. Tests und Recherche haben das ergeben:
Vielen, vielen Dank das Du so geduldig die Erklär-Bär Rolle übernommen hast!
Beste Grüsse
Danke für die umfassende Auskunft!
Aussage 1:
TopDown:
Wenn ich Gci verwende, um nur bestimmte Dateientypen im Verzeichnis zu sehen, habe ich
A: 2 Parameter zur Auswahl
A1 "inlcude"
A2 "filter"
B: Pipen und über Where Funkton gehen
Korrekt?
Aussage 2:
Diesen Abschnitt habe ich jetzt drei Mal gelesen und denke noch immer darüber nach...
A:
ACHTUNG! Hier fehlt etwas ganz entscheidendes! Man muss bei Verwendung von -Include beachten das es nur
richtig funktioniert wenn man entweder den Schalter -recurse verwendet
richtig funktioniert wenn man entweder den Schalter -recurse verwendet
Es soll nur das lokale Verzeichnis überprüft werden. Also ist "-recurse" nicht notwendig.
Natürlich funktioniert es damit. Soeben getestet.
$xlsxFiles = Get-ChildItem -Path $sourceDirectory -recurse -Include *.xlsx,*.xlsm,*.-xls
SS64.COM ist für mich leichter zu verstehen, als die MS Manuals:
This parameter is only effective when the command includes -Recurse to match files
or if the string matches the contents of a directory.
B
oder wenn man damit nicht rekursiv suchen möchte im -Path am Ende ein Sternchen setzen muss, den sonst ist das > Ergebnis leer! Eine der Eigenheiten von Get->ChildItem> oder wenn man damit nicht rekursiv suchen möchte im
Path am Ende ein Sternchen setzen muss, den sonst ist das Ergebnis leer! Eine der Eigenheiten von Get->ChildItem
Path am Ende ein Sternchen setzen muss, den sonst ist das Ergebnis leer! Eine der Eigenheiten von Get->ChildItem
Das verstehe ich nicht. Die Aussage dieses Satzes wäre in einem Beispiel:
Sollte nicht gehen: Get-ChildItem -Path "X:\000 Selektion\99 Ablage" -Include *.xlsx,*.xlsm,*.pdf
Sollte gehen: Get-ChildItem -Path "X:\000 Selektion\99 Ablage*" -Include *.xlsx,*.xlsm,*.pdf
Ein Test ergibt, dass beide Befehle kein Resultat anzeigen. Könntest Du rein aus Neugierde, den Sachverhalt mit dem Stern in einfacher Sprache verdeutlichen?
Aussage 3:
Where-object habe ich mit der Syntax geschludert. Mir selbst ein Bein gestellt. Deine Variante funktioniert natürlich:
Get-Childitem -Path "X:\000 Selektion\99 Ablage" -File | where-object {$_.Extension -in ".xlsm",".xlsx",".pdf"} Aussage 4:
GCI und Aliase. Der Sachverhalt ist mir bekannt. Viele Lösungen von Praktikern verwenden die CMD Befehle.
Aus Zeitgründen kann ich dazu weder Argumente noch Beispiele liefern.
Last but not least:
Du erwähnst "-Filter" nicht. Zitat von SS64.com:
A filesystem -filter will use the old Win32/DOS syntax - see the wildcards page for details.
Filters are slightly more efficient than -include/-exclude, because the provider
applies the filter when retrieving the objects, rather than having
PowerShell filter the objects after they are retrieved.
Mit -Filter lässt sich nur ein Muster angeben. Tests und Recherche haben das ergeben:
Get-ChildItem -Path "X:\000 Selektion\99 Ablage" -Filter "*.pdf" Vielen, vielen Dank das Du so geduldig die Erklär-Bär Rolle übernommen hast!
Beste Grüsse
Zitat von @PeterGyger:
Aussage 1:
TopDown:
Wenn ich Gci verwende, um nur bestimmte Dateientypen im Verzeichnis zu sehen, habe ich
A: 2 Parameter zur Auswahl
A1 "inlcude"
A2 "filter"
B: Pipen und über Where Funkton gehen
Korrekt?
Jepp.Aussage 1:
TopDown:
Wenn ich Gci verwende, um nur bestimmte Dateientypen im Verzeichnis zu sehen, habe ich
A: 2 Parameter zur Auswahl
A1 "inlcude"
A2 "filter"
B: Pipen und über Where Funkton gehen
Korrekt?
Aussage 2:
Diesen Abschnitt habe ich jetzt drei Mal gelesen und denke noch immer darüber nach...
A:
Es soll nur das lokale Verzeichnis überprüft werden. Also ist "-recurse" nicht notwendig.
Natürlich funktioniert es damit. Soeben getestet.
$xlsxFiles = Get-ChildItem -Path $sourceDirectory -recurse -Include *.xlsx,*.xlsm,*.-xls
SS64.COM ist für mich leichter zu verstehen, als die MS Manuals:
This parameter is only effective when the command includes -Recurse to match files
or if the string matches the contents of a directory.
B
Das verstehe ich nicht. Die Aussage dieses Satzes wäre in einem Beispiel:
Sollte nicht gehen: Get-ChildItem -Path "X:\000 Selektion\99 Ablage" -Include *.xlsx,*.xlsm,*.pdf
Sollte gehen: Get-ChildItem -Path "X:\000 Selektion\99 Ablage*" -Include *.xlsx,*.xlsm,*.pdf
Ein Test ergibt, dass beide Befehle kein Resultat anzeigen. Könntest Du rein aus Neugierde, den Sachverhalt mit dem Stern in einfacher Sprache verdeutlichen?
Dein zweiter Befehlt ist falsch es fehlt der Backslash vor dem Sternchen! Bitte meinen Code oben genau lesen!Diesen Abschnitt habe ich jetzt drei Mal gelesen und denke noch immer darüber nach...
A:
ACHTUNG! Hier fehlt etwas ganz entscheidendes! Man muss bei Verwendung von -Include beachten das es nur
richtig funktioniert wenn man entweder den Schalter -recurse verwendet
richtig funktioniert wenn man entweder den Schalter -recurse verwendet
Es soll nur das lokale Verzeichnis überprüft werden. Also ist "-recurse" nicht notwendig.
Natürlich funktioniert es damit. Soeben getestet.
$xlsxFiles = Get-ChildItem -Path $sourceDirectory -recurse -Include *.xlsx,*.xlsm,*.-xls
SS64.COM ist für mich leichter zu verstehen, als die MS Manuals:
This parameter is only effective when the command includes -Recurse to match files
or if the string matches the contents of a directory.
B
oder wenn man damit nicht rekursiv suchen möchte im -Path am Ende ein Sternchen setzen muss, den sonst ist das > Ergebnis leer! Eine der Eigenheiten von Get->ChildItem> oder wenn man damit nicht rekursiv suchen möchte im
Path am Ende ein Sternchen setzen muss, den sonst ist das Ergebnis leer! Eine der Eigenheiten von Get->ChildItem
Path am Ende ein Sternchen setzen muss, den sonst ist das Ergebnis leer! Eine der Eigenheiten von Get->ChildItem
Das verstehe ich nicht. Die Aussage dieses Satzes wäre in einem Beispiel:
Sollte nicht gehen: Get-ChildItem -Path "X:\000 Selektion\99 Ablage" -Include *.xlsx,*.xlsm,*.pdf
Sollte gehen: Get-ChildItem -Path "X:\000 Selektion\99 Ablage*" -Include *.xlsx,*.xlsm,*.pdf
Ein Test ergibt, dass beide Befehle kein Resultat anzeigen. Könntest Du rein aus Neugierde, den Sachverhalt mit dem Stern in einfacher Sprache verdeutlichen?
Steht übrigens auch so in der Doku zu Get-ChildItem in Beispiel 4
Get-ChildItem -Path "X:\000 Selektion\99 Ablage\*" -Include *.xlsx,*.xlsm,*.pdf Du erwähnst "-Filter" nicht. Zitat von SS64.com:
A filesystem -filter will use the old Win32/DOS syntax - see the wildcards page for details.
Filters are slightly more efficient than -include/-exclude, because the provider
applies the filter when retrieving the objects, rather than having
PowerShell filter the objects after they are retrieved.
Mit -Filter lässt sich nur ein Muster angeben. Tests und Recherche haben das ergeben:
Richtig in Filter funktionieren nur die Dateisystemfilter wie in der CMD, du hattest aber nach mehrfacher Filterung gefragt deswegen habe ich das -Filter beispiel weggelassen das kanntest du ja selbst bereits ...A filesystem -filter will use the old Win32/DOS syntax - see the wildcards page for details.
Filters are slightly more efficient than -include/-exclude, because the provider
applies the filter when retrieving the objects, rather than having
PowerShell filter the objects after they are retrieved.
Mit -Filter lässt sich nur ein Muster angeben. Tests und Recherche haben das ergeben:
Get-ChildItem -Path "X:\000 Selektion\99 Ablage" -Filter "*.pdf"
Auf die Gefahr hin, dass ich wiederhole was @7907292512 schon geschrieben hat, mache ich es trotzdem. Manchmal hilft es dem Verständnis, wenn man es nochmal mit anderen Worten und Wegen erklärt bekommt.
In beiden gibst du ein oder mehrere Pattern, also Muster, an.
Pipen bedeutet, dass du das vorherige Ergebnis an den folgenden Befehl übergibts. Und da kommt der Umstand zum Tragen, dass Powershell so gut wie alle Ergebnisse als Object liefert.
deines:
richtig:
kann aber auch in der Verwendung eines Netzlaufwerk-Buchstabens, der Session und dem Scope unter dem Powershell läuft (siehe) liegen. mit dem FQDN funktionierte es bei mir bisher immer.
Zitat von @PeterGyger:
Wenn ich Gci verwende, um nur bestimmte Dateientypen im Verzeichnis zu sehen, habe ich
A: 2 Parameter zur Auswahl
A1 "inlcude"
Wenn ich Gci verwende, um nur bestimmte Dateientypen im Verzeichnis zu sehen, habe ich
A: 2 Parameter zur Auswahl
A1 "inlcude"
- -Include => String-Array
-include "*.ab","*.cd","*.ef",".usw" A2 "filter"
- -Filter => Single-String
-filter "nur ein*Single String*" B: Pipen und über Where Funkton gehen
Korrekt?
Mit Where-Object filterst du das Ergebnis, mit -Include oder -Filter filterst du direkt bei der Suche und bekommst direkt das richtige Ergebnis. Where-Object ist unter Umständen wesentlich langsamer.Korrekt?
Pipen bedeutet, dass du das vorherige Ergebnis an den folgenden Befehl übergibts. Und da kommt der Umstand zum Tragen, dass Powershell so gut wie alle Ergebnisse als Object liefert.
Aussage 2:
Diesen Abschnitt habe ich jetzt drei Mal gelesen und denke noch immer darüber nach...
A:
Es soll nur das lokale Verzeichnis überprüft werden. Also ist "-recurse" nicht notwendig.
Natürlich funktioniert es damit. Soeben getestet.
$xlsxFiles = Get-ChildItem -Path $sourceDirectory -recurse -Include *.xlsx,*.xlsm,*.-xls
SS64.COM ist für mich leichter zu verstehen, als die MS Manuals:
This parameter is only effective when the command includes -Recurse to match files
or if the string matches the contents of a directory.
Ganz richtig! -Recurse brauchst du nur, wenn du auch alle Sub-Folder durchsuchen willst. Mit -Depth kannst du dann die Pfadtiefe festlegenDiesen Abschnitt habe ich jetzt drei Mal gelesen und denke noch immer darüber nach...
A:
ACHTUNG! Hier fehlt etwas ganz entscheidendes! Man muss bei Verwendung von -Include beachten das es nur
richtig funktioniert wenn man entweder den Schalter -recurse verwendet
richtig funktioniert wenn man entweder den Schalter -recurse verwendet
Es soll nur das lokale Verzeichnis überprüft werden. Also ist "-recurse" nicht notwendig.
Natürlich funktioniert es damit. Soeben getestet.
$xlsxFiles = Get-ChildItem -Path $sourceDirectory -recurse -Include *.xlsx,*.xlsm,*.-xls
SS64.COM ist für mich leichter zu verstehen, als die MS Manuals:
This parameter is only effective when the command includes -Recurse to match files
or if the string matches the contents of a directory.
-Recurse -Depth 3B
Das verstehe ich nicht. Die Aussage dieses Satzes wäre in einem Beispiel:
Sollte nicht gehen: Get-ChildItem -Path "X:\000 Selektion\99 Ablage" -Include *.xlsx,*.xlsm,*.pdf
Sollte gehen: Get-ChildItem -Path "X:\000 Selektion\99 Ablage*" -Include *.xlsx,*.xlsm,*.pdf
Das Sternchen am Ende nach dem Backslash weist PS an alles ab dem letzten Backslash mitzunehmen. Das ist eine Eigenheit von einigen Methoden die dazu da sind etwas zu durchsuchen. Etwa:oder wenn man damit nicht rekursiv suchen möchte im -Path am Ende ein Sternchen setzen muss, den sonst ist das > Ergebnis leer! Eine der Eigenheiten von Get->ChildItem> oder wenn man damit nicht rekursiv suchen möchte im
Path am Ende ein Sternchen setzen muss, den sonst ist das Ergebnis leer! Eine der Eigenheiten von Get->ChildItem
Path am Ende ein Sternchen setzen muss, den sonst ist das Ergebnis leer! Eine der Eigenheiten von Get->ChildItem
Das verstehe ich nicht. Die Aussage dieses Satzes wäre in einem Beispiel:
Sollte nicht gehen: Get-ChildItem -Path "X:\000 Selektion\99 Ablage" -Include *.xlsx,*.xlsm,*.pdf
Sollte gehen: Get-ChildItem -Path "X:\000 Selektion\99 Ablage*" -Include *.xlsx,*.xlsm,*.pdf
- Get-Item
- Get-ItemProperty
- Get-ChildItem
- usw.
Ein Test ergibt, dass beide Befehle kein Resultat anzeigen. Könntest Du rein aus Neugierde, den Sachverhalt mit dem Stern in einfacher Sprache verdeutlichen?
Das Problem liegt hier eindeutig in der falschen Syntax:deines:
Get-ChildItem -Path "X:\000 Selektion\99 Ablage*" -Include *.xlsx,*.xlsm,*.pdf richtig:
Get-ChildItem -Path "X:\000 Selektion\99 Ablage\*" -Include *.xlsx,*.xlsm,*.pdf kann aber auch in der Verwendung eines Netzlaufwerk-Buchstabens, der Session und dem Scope unter dem Powershell läuft (siehe) liegen. mit dem FQDN funktionierte es bei mir bisher immer.
Aussage 3:
Where-object habe ich mit der Syntax geschludert. Mir selbst ein Bein gestellt. Deine Variante funktioniert natürlich:
Aussage 4:
GCI und Aliase. Der Sachverhalt ist mir bekannt. Viele Lösungen von Praktikern verwenden die CMD Befehle.
Aus Zeitgründen kann ich dazu weder Argumente noch Beispiele liefern.
Powershell-Aliases sind nicht das gleiche wie ein CMD, aka %Comspec% Befehl. Powershell versteht CMD. Darum geht das auch. Ein Alias ist ein Shortname für eine Funktion (siehe).Where-object habe ich mit der Syntax geschludert. Mir selbst ein Bein gestellt. Deine Variante funktioniert natürlich:
Get-Childitem -Path "X:\000 Selektion\99 Ablage" -File | where-object {$_.Extension -in ".xlsm",".xlsx",".pdf"} Aussage 4:
GCI und Aliase. Der Sachverhalt ist mir bekannt. Viele Lösungen von Praktikern verwenden die CMD Befehle.
Aus Zeitgründen kann ich dazu weder Argumente noch Beispiele liefern.
Hallo mayho33
Diese Woche war ich etwas "unter Wasser". Daher kann ich Dir erst jetzt für den ausführlichen Post danken.
Im Detail:
Include = "Array" und Filter eine Variable - Unterschied ist klar.
Eine Variable hat einen Wert. D.h. die Summe aller Bytes die der Var zugwiesen wurden, werden als Teil der Var behandelt. Ein Stern ist ein Zeichen und kein Wildcard. Im Falle einer String Var kann ich sie mit Befehlen wie "substring" differenziert auslesen. Aber es ist ein Wert bzw. Pattern oder Muster.
Dasselbe gilt für ein Array. Nur das hier mehrere Werte durch Komma separiert definiert werden.
Wenn der Code gepasert wird, erfolgt keine Interpretation z.B. von Wildcards.
Stern und Include bzw. andere Cmdlets verstanden. Syntax Error auf meiner Seite.
Unklar
Der Sachverhalt mit den Alias ist nicht eindeutig.
"Dir" ist sowohl ein Alias für GCI als auch ein CMD Befehl
Einfache Tests mit "Dir" ergeben, dass es ein Alias ist. Und auch andere Befehle aus der Shell CMD funktionieren nicht wie gewohnt. Bzw. nicht vollständig.
Ich habe in der Vergangenheit Beispiele von PS Code mit CMD Befehlen gesehen. Mit der Begründung, dass es anders nicht oder nur wesentlich komplizierter gehe. Jedoch habe ich diese Beispiele nicht gespeichert. So viele spannende Punkte und so wenig Zeit...
Last but not least - nochmals danke für Deine Zeit und das ich nun weiss, dass ISE in Firmen noch verwendet
wird.
Beste Grüsse
Diese Woche war ich etwas "unter Wasser". Daher kann ich Dir erst jetzt für den ausführlichen Post danken.
Im Detail:
Include = "Array" und Filter eine Variable - Unterschied ist klar.
In beiden gibst du ein oder mehrere Pattern, also Muster, an.
Maximal unklar. Eine Variable hat einen Wert. D.h. die Summe aller Bytes die der Var zugwiesen wurden, werden als Teil der Var behandelt. Ein Stern ist ein Zeichen und kein Wildcard. Im Falle einer String Var kann ich sie mit Befehlen wie "substring" differenziert auslesen. Aber es ist ein Wert bzw. Pattern oder Muster.
Dasselbe gilt für ein Array. Nur das hier mehrere Werte durch Komma separiert definiert werden.
Wenn der Code gepasert wird, erfolgt keine Interpretation z.B. von Wildcards.
Stern und Include bzw. andere Cmdlets verstanden. Syntax Error auf meiner Seite.
Unklar
Der Sachverhalt mit den Alias ist nicht eindeutig.
"Dir" ist sowohl ein Alias für GCI als auch ein CMD Befehl
Einfache Tests mit "Dir" ergeben, dass es ein Alias ist. Und auch andere Befehle aus der Shell CMD funktionieren nicht wie gewohnt. Bzw. nicht vollständig.
Ich habe in der Vergangenheit Beispiele von PS Code mit CMD Befehlen gesehen. Mit der Begründung, dass es anders nicht oder nur wesentlich komplizierter gehe. Jedoch habe ich diese Beispiele nicht gespeichert. So viele spannende Punkte und so wenig Zeit...
Last but not least - nochmals danke für Deine Zeit und das ich nun weiss, dass ISE in Firmen noch verwendet
wird.
Beste Grüsse
Zitat von @PeterGyger:
Eine Variable hat einen Wert. D.h. die Summe aller Bytes die der Var zugwiesen wurden, werden als Teil der Var behandelt. Ein Stern ist ein Zeichen und kein Wildcard.
Eine Variable hat einen Wert. D.h. die Summe aller Bytes die der Var zugwiesen wurden, werden als Teil der Var behandelt. Ein Stern ist ein Zeichen und kein Wildcard.
Achtung das ist so nicht richtig!
Viele CMDLets haben oftmals zwei Parameter einmal -Path und dann auch noch -LiteralPath. Der Unterschied bei beiden ist das beim ersteren Wildcards bzw. die aktuell gültigen Dateisystemfilter interpretiert werden also "?" "*" usw.,, wohingegen beim zweiten Parameter(-Literalstring) der String "literal" also so wie er geschrieben ist übernommen wird!
Einfache Tests mit "Dir" ergeben, dass es ein Alias ist. Und auch andere Befehle aus der Shell CMD funktionieren nicht wie gewohnt. Bzw. nicht vollständig.
Die Powershell-Umgebung ist eben keine CMD-Umgebung. Man kann aber jederzeit native in den Interpreter eingebauten CMD Befehle explizit auch in der Powershell nutzen wenn man den Interpreter davor setzt, also bspw. cmd /c dirEs gilt wie immer in der Powershell das man Befehle die nicht im Path definiert sind immer mit vollständiger Pfaddefinition angeben muss.
Dir ist genauso wie echo, for usw. ein CMD interner Befehl für den es keine externe Datei gibt. Er ist im Interpreter also in der cmd.exe eingebaut und deswegen selbst kein Teil der Powershell, bzw. dort nur über den Alias "dir" auf Get-ChildItem gemappt.
Hallo Siddius
Vielen Dank das Du Dir Zeit für meine Fragen nimmst.
-Path und -Literalpath
Die Ausgangslage ist diese Aussage:
Das Du jetzt den Kontext, um "-Path" und "-Literalpath" erweiterst, ändert kein Jota an meinem Standpunkt.
In diesen Bsp oben kann ich kein Pattern erkennen. Bzw. es werden keine interpretiert. Das was nach "-filter=" folgt, ist eine Var. Da wird nichts ausgewertet. Andernfalls könnte man eingeben
In dem Beispiel oben wurde weder der Parameter "-path" noch "-literalpath" verwendet. Anzunehmender
weise hat das Cmdlet CGI einen Default und der wird "-path" sein. Dann müsste ich Deine Information so verstehen:
Wenn man mit dem Cmdlet GCI den Parameter "-literalpath" verwendet, wird der Inhalt einer String Variable auf Wildcards ausgewertet.
Dieser Aussage widerspricht die Website ss64.com. Zum Cmdlet GCI - Parameter -filter - wird keine Abhängigkeit zu anderen Parametern erwähnt.
Auch in der Praxis kann ich Deinen Ansatz nicht erfolgreich umsetzen
"interne Befehle der CMD"
Die Ausgangslage war die Angabe des TN mayho33 zu "Dir"
Meine Sicht:
Powershell versteht CMD nicht. Powershell und CMD sind Shells. Jede hat Ihre Befehle, Funktionen, etc.
Man kann über den Aufruf der Shell (cmd /c") Befehle der CMD Shell in PS aufrufen. Nur so.
Externe Befehle der CMD Shell können wie jede andere Exe Datei identisch aufgerufen werden.
SysInternal Tools verändern ihre Syntax / Ausgaben auch nicht abhängig von der Shell von der sie aufgerufen wurden.
Beste Grüsse
Vielen Dank das Du Dir Zeit für meine Fragen nimmst.
-Path und -Literalpath
Die Ausgangslage ist diese Aussage:
Das Du jetzt den Kontext, um "-Path" und "-Literalpath" erweiterst, ändert kein Jota an meinem Standpunkt.
In diesen Bsp oben kann ich kein Pattern erkennen. Bzw. es werden keine interpretiert. Das was nach "-filter=" folgt, ist eine Var. Da wird nichts ausgewertet. Andernfalls könnte man eingeben
gci .\ -filter "*.PDF *.xls?" In dem Beispiel oben wurde weder der Parameter "-path" noch "-literalpath" verwendet. Anzunehmender
weise hat das Cmdlet CGI einen Default und der wird "-path" sein. Dann müsste ich Deine Information so verstehen:
Wenn man mit dem Cmdlet GCI den Parameter "-literalpath" verwendet, wird der Inhalt einer String Variable auf Wildcards ausgewertet.
Dieser Aussage widerspricht die Website ss64.com. Zum Cmdlet GCI - Parameter -filter - wird keine Abhängigkeit zu anderen Parametern erwähnt.
Auch in der Praxis kann ich Deinen Ansatz nicht erfolgreich umsetzen
"interne Befehle der CMD"
Die Ausgangslage war die Angabe des TN mayho33 zu "Dir"
Powershell-Aliases sind nicht das gleiche wie ein CMD, aka %Comspec% Befehl. Powershell versteht CMD. Darum geht das auch
Meine Sicht:
Powershell versteht CMD nicht. Powershell und CMD sind Shells. Jede hat Ihre Befehle, Funktionen, etc.
Man kann über den Aufruf der Shell (cmd /c") Befehle der CMD Shell in PS aufrufen. Nur so.
Externe Befehle der CMD Shell können wie jede andere Exe Datei identisch aufgerufen werden.
SysInternal Tools verändern ihre Syntax / Ausgaben auch nicht abhängig von der Shell von der sie aufgerufen wurden.
Beste Grüsse
Zitat von @PeterGyger:
Diese Woche war ich etwas "unter Wasser". Daher kann ich Dir erst jetzt für den ausführlichen Post danken.
Servus @PeterGyger,Diese Woche war ich etwas "unter Wasser". Daher kann ich Dir erst jetzt für den ausführlichen Post danken.
Sorry! muss ein wenig schmunzeln 😂🤷♂️
Im Detail:
Include = "Array" und Filter eine Variable - Unterschied ist klar.
Include = "Array" und Filter eine Variable - Unterschied ist klar.
Ja, nur scheint dir der Unterschied bzw. die Gemeinsamkeit zwischen/von Array und Variable nicht ganz klar zu sein. Im Grunde sind beides Variablen. Das eine ist einfach nur eine einzelne Variable und das andere ein Sammlung an Variablen.
Bsp:
$myStrVar = "StringVariable";
$myIntVar = 1010101;
$myObjVar = New-Object System.Collections.Generic.List[String];
$mySingleDimensionArr = @("eins","zwei","drei","vier");
$myMultiDomensionalArr= @($mySingleDimensionArr, $myObjVar, $myIntVar);
Get-Help about_propertiesIn beiden gibst du ein oder mehrere Pattern, also Muster, an.
Maximal unklar. Ein Muster oder pattern ist etwas wiedererkannbares. Beispielsweise könnte dies das Pattern für eine erkennungsdienstliche Suche zu einer Person sein...
* white
* male
* 45
* 180
* 92Get-ChildItem -Path "X:\000 Selektion\99 Ablage\*" -Include *.xlsx,*.xlsm,*.pdf $test = "a white male body, about 45 years old, 180 cm tall and weighs 92 kilograms...";
$pattern = "(MALE|wHiTe|180|45|kILoGrams)";
$regexOption = [System.Text.RegularExpressions.RegexOptions]::IgnoreCase
[regex]::Matches($test, $pattern, $regexOption).valueget-help about_Regular_ExpressionsEin Stern ist ein Zeichen und kein Wildcard.
Das würde stimmen wenn wir "*" rein als die Summe seiner Bytes oder ASCII verstehen würden. In jeder Code-Language gibt es aber Ausnahmen, Überladungen, usw. PS versteht ein "*" als Wildcard. Auch C#, C++, RegularExpressions, sogar VBScript in bestimmten Fällen.Im Falle einer String Var kann ich sie mit Befehlen wie "substring" differenziert auslesen. Aber es ist ein Wert bzw. Pattern oder Muster.
Siehe dazu:
- get-help about_Regular_Expressions
- get-help about_Split
Dasselbe gilt für ein Array. Nur das hier mehrere Werte durch Komma separiert definiert werden.
Wenn der Code gepasert wird, erfolgt keine Interpretation z.B. von Wildcards.
Stern und Include bzw. andere Cmdlets verstanden. Syntax Error auf meiner Seite.
Ähh.. Jetzt habe ich Tilt. Verstanden und Syntax Error in einem Satz löt bei mir leider einen Lauifzeitfehler aus 🤔🤔🤷♂️. Hoffe oben habe ich es verständlich erklärt.Unklar
Der Sachverhalt mit den Alias ist nicht eindeutig.
"Dir" ist sowohl ein Alias für GCI als auch ein CMD Befehl
Einfache Tests mit "Dir" ergeben, dass es ein Alias ist. Und auch andere Befehle aus der Shell CMD funktionieren nicht wie gewohnt. Bzw. nicht vollständig.
Wie @7907292512 schon schreibt ists die PS-Shell nicht vergleichbar mit der %Comspec%. Da will ich gar nichts mehr weiter ausführen. Aber ich muss dir recht geben. "Dir" ist wirklich ein Alias. Ich verwende nicht gerne Aliases, weil sie den Code schlecht leserlich machen. Bei ~2200 Funktionen im der Standardlibrary von PS 5.x mit je 2 oder 3 Aliases in jeder 2. oder 3. Funktion... Und wenn dann noch CmdLets anderer Tools dazu kommen (etwa System Center); Das willst du dir nicht merken müssen.... Ich weise meine Abteilungskollegen immer an den Code lieber leserlich zu schreiben anstatt sich ein paar Zeilen Code zu sparen.Der Sachverhalt mit den Alias ist nicht eindeutig.
"Dir" ist sowohl ein Alias für GCI als auch ein CMD Befehl
Einfache Tests mit "Dir" ergeben, dass es ein Alias ist. Und auch andere Befehle aus der Shell CMD funktionieren nicht wie gewohnt. Bzw. nicht vollständig.
Ich habe in der Vergangenheit Beispiele von PS Code mit CMD Befehlen gesehen. Mit der Begründung, dass es anders nicht oder nur wesentlich komplizierter gehe. Jedoch habe ich diese Beispiele nicht gespeichert. So viele spannende Punkte und so wenig Zeit...
Man kann in der ISE ganz leicht ein Codesnipped anlegen.get-help New-IseSnippetLast but not least - nochmals danke für Deine Zeit und das ich nun weiss, dass ISE in Firmen noch verwendet
wird.
Gerne!wird.
Für Korinthenkacker doch gerne 😂
https://learn.microsoft.com/de-de/powershell/module/microsoft.powershell ...
Kann ja so niemals funktionieren, weil das selbst in der CMD noch nie funktioniert hat. Du kannst dort nicht mehrfach filtern und einfach mit Leerzeichen trennen, so wie mit include und einem Array.
Jetzt ist aber mal genug Korinthen gekackt 😂und ab die Doku lesen dann wird alles gut!
Das Du jetzt den Kontext, um "-Path" und "-Literalpath" erweiterst, ändert kein Jota an meinem Standpunkt.
Du hast zu feste Standpunkte sei doch endlich mal flexibler und halte dich an Standards die selbst unter der CMD noch Gültigkeit besitzen ...In diesen Bsp oben kann ich kein Pattern erkennen. Bzw. es werden keine interpretiert. Das was nach "-filter=" folgt, ist eine Var. Da wird nichts ausgewertet. Andernfalls könnte man eingeben
Sicher doch -Filter ist nichts anderes als wenn du einen Wildcard im -Path angeben würdest nur als separater Parameter ausgeführt!Anzunehmender
weise hat das Cmdlet CGI einen Default und der wird "-path" sein.
Nicht annehmen sondern Nachschlagen genau das steht nämlich in der Doku, da solltest du öfter mal rein achauen, Stichwort "unnamed parameter", dann müsstest du nicht immer in der Gegend rum raten und vermuten...weise hat das Cmdlet CGI einen Default und der wird "-path" sein.
Wenn man mit dem Cmdlet GCI den Parameter "-literalpath" verwendet, wird der Inhalt einer String Variable auf Wildcards ausgewertet.
Eben nicht!! Habe ich oben ja ganz klar dargelegt! Ich habe geschrieben das bei LiteralPath eben keine Interpretation dieser Sonderzeichen stattfindet. Du liest scheinbar quer, oder sprichst eine andere Sprache 🙃😀https://learn.microsoft.com/de-de/powershell/module/microsoft.powershell ...
-LiteralPath
Gibt einen Pfad zu einem oder mehreren Speicherorten an. Der Wert von LiteralPath wird genau so verwendet, wie er eingegeben wird. Es werden keine Zeichen als Platzhalter interpretiert. Wenn der Pfad Escapezeichen enthält, müssen Sie ihn in einfache Anführungszeichen einschließen. Einzelne Anführungszeichen weisen PowerShell an, keine Zeichen als Escapesequenzen zu interpretieren.
Gibt einen Pfad zu einem oder mehreren Speicherorten an. Der Wert von LiteralPath wird genau so verwendet, wie er eingegeben wird. Es werden keine Zeichen als Platzhalter interpretiert. Wenn der Pfad Escapezeichen enthält, müssen Sie ihn in einfache Anführungszeichen einschließen. Einzelne Anführungszeichen weisen PowerShell an, keine Zeichen als Escapesequenzen zu interpretieren.
Auch in der Praxis kann ich Deinen Ansatz nicht erfolgreich umsetzen
Kann ja so niemals funktionieren, weil das selbst in der CMD noch nie funktioniert hat. Du kannst dort nicht mehrfach filtern und einfach mit Leerzeichen trennen, so wie mit include und einem Array.
Jetzt ist aber mal genug Korinthen gekackt 😂und ab die Doku lesen dann wird alles gut!
1
