capture-Prozess stdout und stderr in die richtige Reihenfolge

Ich einen Prozess starten von C# wie folgt:

public bool Execute()
{
    ProcessStartInfo startInfo = new ProcessStartInfo();

    startInfo.Arguments =  "the command";
    startInfo.FileName = "C:\\MyApp.exe";

    startInfo.UseShellExecute = false;
    startInfo.RedirectStandardOutput = true;
    startInfo.RedirectStandardError = true;

    Log.LogMessage("{0} {1}", startInfo.FileName, startInfo.Arguments);

    using (Process myProcess = Process.Start(startInfo))
    {
        StringBuilder output = new StringBuilder();
        myProcess.OutputDataReceived += delegate(object sender, DataReceivedEventArgs e)
        {
            Log.LogMessage(Thread.CurrentThread.ManagedThreadId.ToString() + e.Data);
        };
        myProcess.ErrorDataReceived += delegate(object sender, DataReceivedEventArgs e)
        {
            Log.LogError(Thread.CurrentThread.ManagedThreadId.ToString() +  " " + e.Data);            
        };

        myProcess.BeginErrorReadLine();
        myProcess.BeginOutputReadLine();

        myProcess.WaitForExit();

    }

    return false;
}

Aber dieser hat ein problem..., wenn die app in Frage, schreibt auf std-out und std err, in dieser Reihenfolge:

std out: msg 1
std err: msg 2
std out: msg 3

Dann die Ausgabe sehe ich aus den Protokollen ist:

msg 2
msg 1
msg 3

Scheint dies zu sein, weil die event-Handler ausgeführt werden, in einem anderen thread. Meine Frage ist also wie kann die Reihenfolge der Prozess schriftlich std err und std-out beibehalten werden?

Ich daran gedacht, mit einem Zeitstempel, aber ich glaube nicht, dass dies funktioniert durch die präventive Natur des threads..

Update: Bestätigt, dass die Verwendung eines Zeitstempels auf die Daten nicht verwenden.

Final update: Die akzeptierte Antwort, die dieses problem löst - aber es hat einen Nachteil, wenn die Ströme zusammengeführt werden, gibt es keine Möglichkeit zu wissen, welche Bach geschrieben wurde. Daher, wenn Sie die Logik der schreiben auf stderr == Fehler, anstatt die app beenden-code, den Sie könnte noch geschraubt werden.

  • Nur als Anregung, haben Sie versucht, ändern der Reihenfolge von BeginErrorReadLine und BeginOutputReadLine Anrufe?
  • Finden Sie die akzeptierte Antwort, dass nicht nicht die Hilfe an alle
InformationsquelleAutor paulm | 2013-08-30
  1. 12

    So weit ich verstehe, Sie wollen, um die Erhaltung der Reihenfolge von stdout/stderr-Nachrichten. Ich sehe keine ANSTÄNDIGE Möglichkeit, dies zu tun mit C# managed-Prozess(Reflexion - ja, böse Unterklassen hacking - ja). Es scheint, dass es ziemlich viel hardcoded.

    Diese Funktionalität hängt nicht davon ab, threads selbst. Wenn Sie möchten, halten Sie die Reihenfolge, STDOUT und STDERROR müssen, verwenden Sie das gleiche behandeln(Puffer). Wenn Sie verwenden Sie den gleichen Puffer, es wird synchronisiert.

    Hier ist ein Ausschnitt aus dem Prozess.cs:

     if (startInfo.RedirectStandardOutput) {
    CreatePipe(out standardOutputReadPipeHandle, 
               out startupInfo.hStdOutput, 
               false);
    } else {
    startupInfo.hStdOutput = new SafeFileHandle(
         NativeMethods.GetStdHandle(
                         NativeMethods.STD_OUTPUT_HANDLE), 
                         false);
}

if (startInfo.RedirectStandardError) {
    CreatePipe(out standardErrorReadPipeHandle, 
               out startupInfo.hStdError, 
               false);
    } else {
    startupInfo.hStdError = new SafeFileHandle(
         NativeMethods.GetStdHandle(
                         NativeMethods.STD_ERROR_HANDLE),
                         false);
}

    wie Sie sehen können, gibt es gonna werden zwei Puffer, und wenn wir haben zwei Puffer, die wir bereits verloren haben, die um Informationen.

    Grundsätzlich müssen Sie, um erstellen Sie Ihr eigenes Process () - Klasse, die kann in diesem Fall behandeln. Traurig? Ja.
    Die gute Nachricht ist, dass es ist nicht schwer, es scheint ziemlich einfach. Hier ist ein code entnommen, StackOverflow, nicht C#, aber genug, um zu verstehen, die der Algorithmus:

    function StartProcessWithRedirectedOutput(const ACommandLine: string; const AOutputFile: string;
  AShowWindow: boolean = True; AWaitForFinish: boolean = False): Integer;
var
  CommandLine: string;
  StartupInfo: TStartupInfo;
  ProcessInformation: TProcessInformation;
  StdOutFileHandle: THandle;
begin
  Result := 0;

  StdOutFileHandle := CreateFile(PChar(AOutputFile), GENERIC_WRITE, FILE_SHARE_READ, nil, CREATE_ALWAYS,
    FILE_ATTRIBUTE_NORMAL, 0);
  Win32Check(StdOutFileHandle <> INVALID_HANDLE_VALUE);
  try
    Win32Check(SetHandleInformation(StdOutFileHandle, HANDLE_FLAG_INHERIT, 1));
    FillChar(StartupInfo, SizeOf(TStartupInfo), 0);
    FillChar(ProcessInformation, SizeOf(TProcessInformation), 0);

    StartupInfo.cb := SizeOf(TStartupInfo);
    StartupInfo.dwFlags := StartupInfo.dwFlags or STARTF_USESTDHANDLES;
    StartupInfo.hStdInput := GetStdHandle(STD_INPUT_HANDLE);
    StartupInfo.hStdOutput := StdOutFileHandle;
    StartupInfo.hStdError := StdOutFileHandle;

    if not(AShowWindow) then
    begin
      StartupInfo.dwFlags := StartupInfo.dwFlags or STARTF_USESHOWWINDOW;
      StartupInfo.wShowWindow := SW_HIDE;
    end;

    CommandLine := ACommandLine;
    UniqueString(CommandLine);

    Win32Check(CreateProcess(nil, PChar(CommandLine), nil, nil, True,
      CREATE_NEW_PROCESS_GROUP + NORMAL_PRIORITY_CLASS, nil, nil, StartupInfo, ProcessInformation));

    try
      Result := ProcessInformation.dwProcessId;

      if AWaitForFinish then
        WaitForSingleObject(ProcessInformation.hProcess, INFINITE);

    finally
      CloseHandle(ProcessInformation.hProcess);
      CloseHandle(ProcessInformation.hThread);
    end;

  finally
    CloseHandle(StdOutFileHandle);
  end;
end;

    Quelle: Zum umleiten von großen output-Menge, die von der Kommandozeile ausgeführt von CreateProcess?

    Anstelle der Datei, die Sie verwenden möchten CreatePipe. Aus der pipe Lesen kann asynchron etwa so:

    standardOutput = new StreamReader(new FileStream(
                       standardOutputReadPipeHandle, 
                       FileAccess.Read, 
                       4096, 
                       false),
                 enc, 
                 true, 
                 4096);

    und BeginReadOutput()

      if (output == null) {
        Stream s = standardOutput.BaseStream;
        output = new AsyncStreamReader(this, s, 
          new UserCallBack(this.OutputReadNotifyUser), 
             standardOutput.CurrentEncoding);
    }
    output.BeginReadLine();
    • Ja, ich würde mich einverstanden mit dieser Antwort. Ich haben eine Menge Forschung zu diesem Thema an diesem Nachmittag und ich denke, das ist der richtige Weg, es zu bekommen. Auch wenn Sie die zugrunde liegenden StreamReaders auf Prozess-für stdout/err, es klingt wie die Peek-Methode blockiert, weil Sie nicht verwenden PeekNamedPipe unter der Haube. All dies gesagt, ich habe mich gefragt, was genau Sie tun müssen. Wenn alles, was Sie über Pflege ist die Erfassung von stdout/stderr in der richtigen Reihenfolge, nicht darum zu kümmern, was was ist, könnten Sie möglicherweise erstellen Sie eine batch-Datei mit 2>&1-trick, um push-alles in stdout. Würde das funktionieren?
    • Im Idealfall würde ich mag in der Lage sein, um sowohl stdout (Ausgabe Verarbeitung) und stdout+stderr (für error reporting). Vielleicht, Haken schreibt die 2 Griffe mit einer gemeinsamen Sperre irgendwie...
    • In meinem Fall über eine batch-Datei mit 2>&1 auch fängt es in der falschen Reihenfolge, ich glaube nicht, dass dies überhaupt möglich ist
    • Ich weiß'tthink 2>&1 funktioniert. Gerade getestet auf meinem .NET-Anwendung und-im Vergleich GetStdHandle(STD_OUPUT) und GetStdHandle(STD_ERROR). Nicht sicher, wie die batch-pipe-Umleitung funktioniert, aber wenn Sie Debuggen, können Sie sehen, dass Sie es nicht machen 2 Griffe, die gleichen. Versuchen Sie umschreiben den Pascal-code, es sollte für Sie arbeiten, paulm.
    • Wenn das funktioniert dann wie wissen Sie, wenn die app geschrieben, um stderr zu erkennen, es war ein problem? Ich glaube, das muss sein, warum die .NETTO Klasse Prozess hat die beiden Pfeifen das gleiche wie cmd.exe?
    • STDOUT/STDERR waren nie böse, nicht bestellt werden. So weit ich sehen Sie jetzt: Sie erhalten entweder eine, oder andere. Wenn Sie können führen Sie den gleichen Vorgang zweimal(einer für stdout, andere für stdout/stderr), dann werden Sie in Ordnung sein. Was Sie tun können: Download ApiMonitor und schauen, wie die Konsole zu schreiben, wird umgesetzt unter der Haube(WriteOut). Sie können tun Prozess-hijacking, das Ihnen erlaubt, abfangen ALLE Anrufe, die vor sich geht - so dass Sie tun, was Sie wollen. Sehen Sie IAT API hooking im Google - nicht eine nette Weise, aber es funktioniert.
    • Was ist mit 3 Griffen, Griff nach stdout, stderr und stdout/stderr in ein Griff, wie Sie vorgeschlagen? Würde dies ermöglichen die "richtigen" bestellen und wissen, ob stderr geschrieben wurde?
    • Hat jemand hatte Erfolg der Umwandlung dieser (Delphi?) code in C#?

    InformationsquelleAutor Erti-Chris Eelmaa
  2. 6

    Während ich Schätze Erti-Chris ' s Antwort (was ist das, Pascal?), Ich dachte, andere vielleicht lieber eine Antwort in einer verwalteten Sprache. Auch, um die Kritiker, die sagen, dass "Sie sollten dies nicht tun", da STDOUT und STDERR werden nicht garantiert, um die Erhaltung der Bestellung: ja, ich weiß, aber manchmal müssen wir interagieren mit Programmen (die wir nicht schreiben), die von uns erwarten, genau das zu tun, korrekte Semantik verdammt werden.

    Hier eine version in C#. Statt der Umgehung der verwalteten Process API durch aufrufen CreateProcess es verwendet einen alternativen Ansatz, der leitet STDERR auf die STANDARDAUSGABE-stream in der Windows-shell. Da UseShellExecute = true nicht tatsächlich die cmd.exe shell (überraschung!), Sie normalerweise nicht verwenden, shell-Umleitungen. Die Problemumgehung ist, starten Sie die cmd.exe shell selbst, die Fütterung unserer real-shell-Programm und Argumente, um Sie manuell.

    Beachten Sie, dass die folgende Lösung geht davon aus, dass Ihre args array ist schon richtig escaped. Ich mag die brute-force-Lösung für die Verwendung der kernel - GetShortPathName nennen, aber Sie sollten wissen, dass es nicht immer angemessen ist, zu verwenden (wenn man z.B. nicht auf NTFS). Auch Sie wirklich wollen, um zu gehen die extra Schritt, Lesen die STDOUT-Puffer asynchron (wie ich unten), denn wenn Sie nicht, das Programm deadlock.

    using System;
using System.Diagnostics;
using System.Text;
using System.Threading;

public static string runCommand(string cpath, string[] args)
{
    using (var p = new Process())
    {
        //notice that we're using the Windows shell here and the unix-y 2>&1
        p.StartInfo.FileName = @"c:\windows\system32\cmd.exe";
        p.StartInfo.Arguments = "/c \"" + cpath + " " + String.Join(" ", args) + "\" 2>&1";
        p.StartInfo.UseShellExecute = false;
        p.StartInfo.RedirectStandardOutput = true;
        p.StartInfo.RedirectStandardError = true;

        var output = new StringBuilder();

        using (var outputWaitHandle = new AutoResetEvent(false))
        {
            p.OutputDataReceived += (sender, e) =>
            {
                //attach event handler
                if (e.Data == null)
                {
                    outputWaitHandle.Set();
                }
                else
                {
                    output.AppendLine(e.Data);
                }
            };

            //start process
            p.Start();

            //begin async read
            p.BeginOutputReadLine();

            //wait for process to terminate
            p.WaitForExit();

            //wait on handle
            outputWaitHandle.WaitOne();

            //check exit code
            if (p.ExitCode == 0)
            {
                return output.ToString();
            }
            else
            {
                throw new Exception("Something bad happened");
            }
        }
    }
}
    • Danke, das ist eigentlich ein sehr einfacher Ansatz. In meinem Fall ist mein Prozess war eine batch-Datei sowieso, so dass dies wirklich entstehen keine zusätzlichen Aufwand oder Komplikationen.
    • Um zu klären, die AutoResetEvent und die e.Data == null gibt es da p.WaitForExit kann passieren, bevor die letzten OutputDataReceived Veranstaltung. Aber wenn die Ausgabe abgeschlossen ist, wird eine abschließende Ereignis gesendet wird mit e.Data == null. Quelle: msdn.microsoft.com/en-us/library/...
    InformationsquelleAutor Dan Barowy
Schreibe einen Kommentar