Ist es möglich, Rohr bedingt in Powershell, d.h. führen Sie ein element einer pipeline nur, wenn eine Bedingung erfüllt ist?

Möchte ich etwas wie das hier tun:

<statement> | <filter1> | <filter2> if <condition> | <filter3> | <filter4> | <filter5>

Den Ergebnissen <statement> starten Sie durch <filter1>, dann laufen Sie durch <filter2> erst wenn <Bedingung> erfüllt ist, dann durch die restlichen Filter, unabhängig davon, ob <filter2> angewendet wurde. Dies ist das äquivalent von:

if (<condition>) {
  <statement> | <filter1> | <filter2> | <filter3> | <filter4> | <filter5>
} else {
  <statement> | <filter1> | <filter3> | <filter4> | <filter5>
}

Dies wäre nützlich bei Funktionen, bei denen ein filter angewendet wird, um die Ergebnismenge nur, wenn ein bestimmter Schalter aufgerufen wurde. Wenn die Auswertung der filter erfolgt früh in einer langen pipeline, schreiben Sie es mit einer äußeren if-block Ergebnisse in eine Menge von Wiederholung von code, vor allem wenn es mehr als eine bedingte filter.

Hier ist ein Beispiel. Die folgende Funktion zeigt die Berechtigungen für ein bestimmtes Konto in ein bestimmtes Verzeichnis-Teilbaum (z.B. Show-AccountPerms \\SERVERX\Marketing DOMAIN\jdoe gibt einen Bericht von Berechtigungen, die der Benutzer DOMAIN\jdoe hat in den Verzeichnisbaum unter \SERVERX\Marketing).

function Show-AccountPerms {
    param (
        [parameter(mandatory = $true)]$rootdir,
        [parameter(mandatory = $true)]$account,
        [switch]$files,
        [switch]$inherited
    )
    gci -r $rootdir `
    |where {$_.psiscontainer} `
    |foreach {
        $dir = $_.fullname
        (get-acl $_.pspath).access `
        | where {$_.isinherited -eq 'False'} `
        |foreach {
            if ($_.identityreference -eq $account) {
                "{0,-25}{1,-35}{2}" -f $_.identityreference, $_.filesystemrights, $dir
            }
        }
    }
}

Standardmäßig, es zeigt nur explizite Berechtigungen (erzwungen durch die | where {$_.isinherited -eq 'False'} filter), und nur auf Verzeichnisse (erzwungen durch die |where {$_.psiscontainer} filter).

Allerdings möchte ich zu ignorieren |where {$_.psiscontainer} wenn die -Dateien-Schalter aufgerufen wird, und ignorieren | where {$_.isinherited -eq 'False'} wenn die geerbte Schalter aufgerufen wird. Dies zu erreichen mit dem äußeren, wenn Blöcke vervierfachen sich den code, und fast 75% wäre es Wiederholung. Gibt es einen Weg, um diese Filter in-line, aber anweisen, powershell gelten nur für die Ihnen von der entsprechende Schalter ist falsch?

Bitte beachten Sie, dass dies nur ein Beispiel, also ich bin nicht daran interessiert, irgendwelche workarounds, die spezifisch für diese Funktion. Ich bin auf der Suche nach einer Antwort auf meine Allgemeine Frage bezüglich Rohrleitungen bedingt, nicht eine Lösung, wie dies zu erreichen bestimmte Aufgabe.

InformationsquelleAutor Adi Inbar | 2012-07-23

7

Können Sie test für beide Bedingungen im filter, so dass das Objekt über die pipeline, wenn entweder eine wahr ist. Wenn dein "Zustand" ist auf der linken Seite des -or Betreiber, machen Sie Ergebnis zu $true wenn Sie nicht möchten, dass Ihre filter-Bedingung getestet.

Zur Nutzung Ihrer Beispiel:
```
| where {$_.psiscontainer}
```
wird:
```
| where {$files -or $_.psiscontainer}
```
und
```
| where {$_.isinherited -eq 'False'}
```
wird
```
| where {$inherited -or $_.isinherited -eq 'False'}
```
Verallgemeinern:
```
<statement> | <filter1> | <filter2> if <condition> | <filter3> | <filter4> | <filter5>
```
wird:
```
<statement> | <filter1> | <-not condition -or filter2> | <filter3> | <filter4> | <filter5>
```
- Das funktioniert auch, wenn der filter ist ein wo - Klausel, nicht aber, wenn der filter sich nicht auswerten einer Bedingung, z.B. wenn Sie möchten, übergeben Sie die Objekte über Select-String <pattern> nur, wenn die Bedingung wahr ist. | -not <condition> -or <filter2> | nicht funktioniert, z.B. | -not $switch -or select-string 'sometext' |. Behalten Sie im Hinterkopf, was "filter" bedeutet, - ein Befehl, der nimmt die pipeline input und sendet die Ergebnisse über die pipeline. Der Zustand test wäre ein Teil des <filter2>, und funktioniert also nur, wenn Sie den filter-Befehl wertet einen Zustand (D. H., ein wo).
InformationsquelleAutor zdan
4

Ich denke, dass die andere Antwort auf diese Frage verkennt, was verlangt wird.

Die Lösung liegt in der folgenden:

... | %{if($_ -match "Something"){DoSomethingWith $_ }else{$_}} | ...

Was wird dies tun, ist alle Elemente durch, um den nächsten filter, mit AUSNAHME derjenigen, die-match "Etwas", in diesem Fall tut es unterschiedliche Logik. Die Logik kann geändert werden, um es übergeben eine geänderte version der pipeline-element anstelle von einer Funktion.
- Die anderen Beantworter der Frage richtig verstanden. Die Idee ist an sich nicht um eine Bedingung zu jedem Objekt und verarbeiten es anders abhängig, ob es erfüllt die Bedingung; es ist zum testen der Bedingung, dass unabhängig von den Objekten in der pipeline und wenden Sie den filter auf all Objekte, sondern nur wenn die Bedingung wahr ist - gleichwertig mit wenn führen Sie die Rohrleitung mit oder ohne Bühne, aber ohne zu wiederholen, eine Menge code. In meinem Beispiel, $files ist nicht etwas, das verglichen wird mit jedem Objekt, es ist ein einfacher Schalter, der bestimmt, ob ein filter angewendet werden, um alle Objekte, die oder keine.
- Jedoch, diese Antwort war hilfreich, dass es eingeführt, die Idee der else - block einfach echo alle Objekte aus, wenn eine Bedingung nicht erfüllt. Die Idee ist if (<condition that has nothing to do with $_>) {<pipe $_ through this filter>}, ansonsten überspringen Sie diesen filter und bewegen Sie auf die nächste Stufe der pipeline. Die else {$_} ist tatsächlich ein workaround für das Letzte Teil, das überspringen der Stufe der pipeline, und sich auf das nächste.
InformationsquelleAutor SpellingD
4

Ich denke du meinst so etwas wie das folgende, welches ich gerade erfunden:
```
function Pipe-If([ScriptBlock]$decider, [ScriptBlock]$pipeElement)
{
    if (&$decider) {
        $pipeElement
    } else {
        {$input}
    }
}

@(1,2,3) | &(Pipe-If {$doDouble} {$input | % { $_ * 2} })
```
Ergebnisse in 2, 4, 6, wenn $doDouble ist $true, und auf $false es ergibt 1, 2, 3.

Der Schlüssel hier ist, dass eine beliebige Rohr-element wie % { $_ * 2} gekapselt werden kann, wie ein ScriptBlock wie {$input | % { $_ * 2 } } ist, und dass es umgewandelt werden kann zurück zu einem Rohr element, indem &.

Ich verwendet http://blogs.msdn.com/b/powershell/archive/2006/12/29/dyi-ternary-operator.aspx für inspiration.

Wichtiger Hinweis. Don ' T verwenden Sie so etwas wie dieses:
```
filter Incorrect-Pipe-If([ScriptBlock]$decider, [ScriptBlock]$pipeElement) {
    if (&$decider) {
        $_ | &$pipeElement
    } else {
        $_
    }
}

@(1,2,3) | Incorrect-Pipe-If {$doDouble} {$_ | % { $_ * 2} }
```
Diese Ursachen % werden mehrfach ausgeführt, einmal für jedes Objekt in der pipeline. Pipe-If korrekt ausführt, die % Befehl nur einmal, und sendet es den gesamten Strom von Objekten.

Im obigen Beispiel ist das kein problem. Aber wenn der Befehl tee bla.txt dann der Unterschied ist wichtig.
- Sieht für mich wie im wesentlichen die gleiche Lösung (workaround, wirklich, da ist es nicht ganz das was ich wollte), wie in meiner Antwort, außer, dass es eingewickelt in eine Funktion. Ich sehe das als einen Schritt in die entgegengesetzte Richtung, weil es wird nicht nur verlassen sich auf die Verfügbarkeit einer externen Funktion, ohne deutlich komprimieren der code eigentlich macht es weniger effizient, weil die Bedingung ist noch, berechnet für jede iteration, aber jetzt macht es einen externen funktionalen Aufruf ausführen der gleichen Logik.
- Sie wurden gefragt, "gibt es einen Weg, um diese Filter in-line, aber anweisen, powershell gelten nur für die Ihnen von der entsprechende Schalter ist falsch?" Und Sie sagte, dass Sie auf der Suche nach "etwas eleganter, würde das auswerten einer Bedingung vor dem filter einmal, um festzustellen, ob ausführen oder überspringen einer Stufe der pipeline." Meine &(Pipe-If {<condition>} {$_| <filter> }) ist genau so eine syntax. Ob oder nicht, um eine Funktion zu verwenden (mit wahrscheinlich keine Auswirkung auf die Leistung) hängt vom Kontext ab, und ob man lieber foreach {if (<condition>) {$_ | <filter>} else {$_} Präferenz.
- Ich bin mir ziemlich sicher, dass die OP entweder missverstanden, Ihre Antwort oder die nicht verstehen, wie, zum Beispiel, für jede tatsächlich funktioniert. Es ist nichts anderes als eine Funktion, wie das ihrige, und alles, was MS bieten könnten, würde sich zwangsläufig die Arbeit in einem der 2 Wege vorgestellt in diesem thread. Das heißt, die Funktion muss entweder blockiert werden (wie diese) oder verlangen, dass der Zustand erneut geprüft werden für jedes element in der pipeline. Ich bin mir ziemlich sicher, dass kein anderer Weg möglich ist, auch in der Theorie, ohne dynamischen code.
InformationsquelleAutor MarnixKlooster ReinstateMonica
4

Sorry, ich wollte nicht aufgeben, diese Frage. Die Antworten, die gegeben wurden, waren nicht das, was ich fuhr, aber ich herausgefunden, einen Weg, es zu tun, kurz nach der Veröffentlichung, und kam nicht wieder auf die Website für eine lange Zeit. Da eine Lösung wurde noch nicht gepostet, hier ist was ich kam mit. Es ist nicht ganz das, was ich im Sinn hatte, als ich die Frage gestellt habe, und es ist nicht zu schön, aber anscheinend ist es der einzige Weg, es zu tun:
```
<statement> | <filter1> | foreach {if (<condition>) {$_ | <filter2>} else {$_} | <filter3> | <filter4> | <filter5>
```
So, in dem Beispiel die Zeile
```
|where {$_.psiscontainer} `
```
geändert
```
|foreach {if (-not $files) {$_ | where {$_.psiscontainer}} else {$_}} `
```
und
```
|where {$_.isinherited -eq 'False'} `
```
geändert
```
|foreach {if (-not $inherited) {$_ | where {$_.isinherited -eq 'False'}} else {$_}} `
```
(Ja, normalerweise würde ich schreiben, dass als |foreach {if ($files) {$_} else {$_ | where {$_.psiscontainer}}}, und |foreach {if ($inherited) {$_} else {$_ | where {$_.isinherited -eq 'False'}}} aber ich habe es auf diese Weise für Klarheit.)

Ich hatte gehofft, es könnte etwas eleganter, würde das auswerten einer Bedingung vor dem filter einmal, um festzustellen, ob ausführen oder überspringen einer Stufe der pipeline. So etwas wie dieses:
```
<statement> | <filter1> | if (<condition>) {<filter2>} | <filter3>
```
(ein spezieller Fall von if, nicht die übliche Bedeutung; ein anderes Schlüsselwort verwendet werden könnte), oder vielleicht
```
<statement> | <filter1> | (<condition>) ? <filter2> | <filter3>
```
$_ wäre ungültig, in dem Zustand, es sei denn, er definiert wird, die außerhalb des aktuellen pipeline, zum Beispiel, wenn die pipeline wird, die in einem switch Anweisung $_ im <condition> finden würde der switch Anweisung $_.

Ich denke, ich werde einen feature-Vorschlag an Microsoft. Dies wäre nicht nur der code eleganter, es wäre effizienter, denn wenn es eine built-in Funktion <condition> ausgewertet werden konnten einmal für die gesamte pipeline, eher dann testen Sie die gleiche unabhängige Bedingung, die in jeder iteration.
- hast du den feature request? Wenn Sie einen link posten, andere Menschen unterstützen diese Anforderung.
InformationsquelleAutor Adi Inbar
0

Weitere option ist, um eine Globale Präferenz-flag (Typ System.Management.Automation.ActionPreference), um dem Benutzer erlauben, um zu bestimmen, ob die pipeline filter etwas tut.

Beispielsweise die $progressPreference kann auf folgende Werte eingestellt:
- SilentlyContinue
- Stop
- Weiter
- Fragen
- Ignorieren
Diese Einstellung fahne ist dann durch Write-Progress zu bestimmen, das gewünschte Verhalten.

zum Beispiel, wenn Sie eine pipeline filter Show-Progress, zählt, die Elemente und zeigt einen Fortschrittsbalken an, es werden dann nur die Anzeige der Balken, wenn $progressPreference eingestellt ist Continue.

Können Sie verwenden, verhält sich die Konstruktion in Ihrer eigenen pipeline Filter.
- Ich bin mir nicht ganz sicher, was Sie versuchen zu sagen, aber es klingt wie Sie falsch verstanden, die Frage zu stellen, denn dies scheint nicht auf alle bezogen. Das ist nicht etwa interaktive user-Entscheidungen, Fortschritt bars, oder Fehlerbehandlung, es ist über die Ausführung eines Abschnitts der Rohrleitung, wenn eine bestimmte unabhängige Bedingung wahr ist, und überspringen diesen Abschnitt, wenn die Bedingung false ist. Von "unabhängig" meine ich nicht bezogen auf den Inhalt der Pipeline-Objekte, d.h., wenn die Bedingung wahr ist, daß der Abschnitt ist ausgeführt, die für alle Objekte; wenn false, ist es nicht ausgeführt, für jedes Objekt.
- Die ursprüngliche Frage eine Lösung benötigt, die zu überspringen pipelines ausführen, dies beschreibt ein Szenario, genau das zu tun, und ohne Rückgriff auf komplexe code-Konstruktionen. Was ist deine Verwirrung?
- Ich hatte gehofft, es gäbe einen Weg, es zu tun "inline", ohne die Notwendigkeit zu halten, neubewerten, bei jeder iteration, eine Bedingung, die unveränderlich sind, für die Dauer der pipeline. Das scheint nicht möglich zu sein. Ich kann Einreichen, es als ein feature-request.
- Wenn Sie denken, hier geht es um die Frage, bitte geben Sie ein Beispiel.
- Diese Lösung funktioniert ohne neubewerten, aber beruht auf einem switch innerhalb der filter, der reagiert auf eine Präferenz Flagge. Nicht alle filter bieten eine solche option, aber es kann für Ihre eigenen Filter.
- Ich verstehe immer noch nicht, wie dieser befasst sich mit der Frage. AFAIK preference flags gelten nur für die Behandlung von Fehlern und die Anzeige von Informationsmeldungen (Achtung, Fortschritt, debugging, Fehler, verbose). Dies scheint zu eng für eine bestimmte Art von filter, die passiert werden gesteuert durch eine zugehörige Präferenz Flagge.
- Ich sehe nicht, wie dies könnte möglicherweise verwendet werden, um die Ausführung eines Where-Object, ForEach-Object, Select-String, oder Tee-Object filter (um nur ein paar Beispiele). Heck, ich kann nicht denken, der eine einzelne Rohrleitung filter, der eingeschaltet werden kann oder aus einer Vorliebe andere Flagge als die, die Sie erwähnt.
- In jedem Fall, verbalen Beschreibungen nur so weit gehen. Wir diskutieren könnten diese die ganze Nacht lang und reden immer aneinander vorbei, aber ein Beispiel wäre klar, ob Sie eine Lösung haben oder falsch verstanden, die Frage. Vergessen Sie Show-Progress, können Sie zeigen, wie die Methode, die Sie vorschlagen, für das Beispiel in meine Frage und Antwort-das überspringen einer Where-Object filter-und Weiterbildung, um den rest der pipeline falls eine gegebene Boolesche variable, deren Wert ermittelt wurde, bevor die pipeline ist wahr?
- Dies funktioniert möglicherweise nicht in diesen Fällen, ich wollte nur zeigen, dass es möglich ist, mit einem anderen Ansatz zu diesem. Ich Stimme mit Ihnen überein, dass es schön wäre, um in der Lage sein, die Anwendung eines pipeline-Schritt bedingt. Ich habe ein ähnlich problem, wo ich möchte group-Funktion ergibt (durch Aufruf Group-Object), aber nur, wenn ein -Summarize Schalter vom Benutzer bereitgestellt wird.
InformationsquelleAutor oɔɯǝɹ
0

Dies ist ähnlich wie Marnix Klooster ' s Antwort ist aber einfacher, mit zu arbeiten. Der Vorteil dieser Formulierung gegenüber, dass man in der syntax des code ausgeführt werden kann. Es ist viel näher an eine normale pipeline-block. Im Grunde brauchen Sie nur zu umschließen, was Sie wollen in {} (geschweifte Klammern).

Beachten Sie, dass, Wie Marnix Schrift dies ist eine blockierende Funktion. Die pipeline, die Ergebnisse sind gesammelt in $Input und die Funktion selbst führt nur einmal. Nur $pipeElement code immer ausführt, mehr als einmal, und auch nur dann, wenn die Ausführung stimmt.
```
function Conditional_Block([bool]$Execute,[ScriptBlock]$PipeElement)
{
    if ($Execute) 
        {$ExecutionContext.InvokeCommand.NewScriptBlock("`$(`$Input|$PipeElement)").invoke()}
    else
        {$input}
}
```
Mit dieser Funktion nicht schon definiert sein! Sie können wirklich wirklich definieren innerhalb der Funktion, wo Sie es verwenden möchten, und lassen es verschwinden, wenn Ihre Funktion beendet ist.

Dem ausführen der parameter aktiviert/deaktiviert den Schritt der Ausführung. Jeder Ausdruck mit boolschem Ergebnis funktioniert. Zum Beispiel $(1 -eq 0) funktioniert genauso wie $false.
```
@(1,2,3)|Conditional_Block $true  {?{$_ -le 2}}|%{"'$_'"}
@(1,2,3)|Conditional_Block $false {?{$_ -le 2}}|%{"'$_'"}
```
InformationsquelleAutor bielawski

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.