Windows Ausgabeströme umleiten

[Vlad T. (vlad_tepesch)]

Hi,
ich würde gern die Ausgabeströme eines Kommandozeilentools umleiten.
ich weiß, dass mit > oder 2> die ströme in verschiendene Dateien 
geleitet werden können. Mit 2>&1, kann stderr auf stdout gelenkt werden

mit | kann sie auf die Eingabe eines Prozessen gelenkt werden.

Ich hätte jetzt gerne jedoch den error-kanal vor der ausgabe auf stdout 
noch durch ein grep geschickt

also etwa
tool > file.txt 2| grep x 2>&1

es müsste also der errorkanal auf die Standardeingabe eines 2. Prozesses 
und von da (nun wäre es ja die Standardausgabe des 2. Prozesses) in den 
stdout des gemultiplext werden.
möglicherweise würde das automatisch passieren, wenn das pipen des 
error-Kanal funktionieren würde.

[Wegstaben V. (wegstabenverbuchsler)]

schnell und schmutzig ohne Pfeife:

tool 1>file.txt 2>grep_roh.txt; grep 'irgendwas' grep_roh.txt > 
gegrept.txt; rm grep_roh.txt; cat file.txt gegrept.txt

[Yalu X. (yalu) (Moderator)]

Wenn ich dein Vorhaben richtig verstanden habe, geht es in der Bash so:

tool 2>&1 >file.txt | grep x

D.h. stdout von tool gelangt direkt in die Datei file.txt, stderr von
tool wird von grep gefiltert, das Ergebnis von grep wird als stdout auf
der Konsole angezeigt.

Da keine Syntaxelemente verwendet werden, die Windows nicht auch kennt,
könnte das auch dort funktionieren.

[Vlad T. (vlad_tepesch)]

hmm, ich versuchs grad auf meinem Privat PC nachzuvollziehen:

perl-script:

for( my $i=0;$i<500; ++$i)
{
  print STDOUT "stdout $i\n";
  print STDERR "stderr $i\n";
  sleep(1);
}

sobald ich versuche die Standardausgabe umzuleiten kommt gar nix mehr 
an.


Yalu X. schrieb:
> Wenn ich dein Vorhaben richtig verstanden habe, geht es in der Bash so:
> tool 2>&1 >file.txt | grep x
>
> D.h. stdout von tool gelangt direkt in die Datei file.txt, stderr von
> tool wird von grep gefiltert, das Ergebnis von grep wird als stdout auf
> der Konsole angezeigt.

werd ich morgen mal probieren.
Ich hätte aber erwartet, dass grep gar nix mehr bekommt, da ja alle 
ausgaben bereits umgeleitet sind. Die file operatoren haben Vorrang.

wenn man 'dir > test.txt | grep DIR' ausführt kommt aus dem grep auch 
nix mehr raus.

[Vlad T. (vlad_tepesch)]

Vlad Tepesch schrieb:
> sobald ich versuche die Standardausgabe umzuleiten kommt gar nix mehr
> an.

ok, das lag am fehlenden flushen des Ausgabepuffer.

local $| = 1;
for( my $i=0;$i<500; ++$i)
{
  print STDOUT "stdout $i\n";
  print STDERR "stderr $i\n";
  select(undef, undef, undef, .25);  # .25s warten
}

Yalu X. schrieb:
> tool 2>&1 >file.txt | grep x

ok, jetzt scheint die stdout in die Datei zu gehen und der stderr auf 
der stdout zu liegen, den grep verarbeitet, aber wie bekomme ich den 
Output jetzt mit in die file.txt gemultiplext.

[Yalu X. (yalu) (Moderator)]

Vlad Tepesch schrieb:
> aber wie bekomme ich den
> Output jetzt mit in die file.txt gemultiplext.

Meinst du damit, dass das stdout und das gegreppte stderr am Ende
gemeinsam in file.txt stehen sollen? In der Bash geht das so:

{ tool 3>&2 2>&1 1>&3 | grep x; } >file.txt 2>&1

Die ersten drei Redirections vertauschen stdout und stderr. Das neue
stdout (also das ursprüngliche stderr) wird gegreppt. Am Schluss wird
die Ausgabe von grep mit dem stderr (also dem ursprünglichen stdout)
zusammengeführt.

Da grep als eigener Prozess läuft und die Daten an mehreren Stellen
zwischengepuffert werden, werden die am Schluss zusammengeführten
Datenströme nicht zeitlich korrekt ineinandergeschachtelt. Außerdem
müsstest du nachsehen, ob unter Windows die Gruppierung von Befehlen
mittels {} überhaupt möglich ist.