Problem: git & StdoutRead

  • Ich führe in einer Konsole im Hintergrund git-Befehle aus und verwerte dann deren Rückgabe in die Konsole. Das klappt auch, solange ein Repo vorhanden ist.

    Nun habe ich folgendes, für mich nicht erklärbares, Verhalten:
    Wende ich eine git-Befehl in einem Ordner ohne Repository an, bekomme ich einen Fehler (ist auch gewünscht zur Auswertung) den ich jedoch nicht auffangen kann. Die Fehlermeldung landet in der Konsole des Aufrufs (SciTE) und die Return-Variable bleibt leer.

  • Ich kanns leider mangels nicht installiertem git nicht testen aber so wie du es jetzt hast, bekomme ich (ohne git) durchaus die entsprechende Rückgabe.

    Daher stellt sich mir die Frage ob es in diesem Fall anders zurück gegeben wird.

  • bekomme ich einen Fehler

    Und Fehler sollten eigentlich von jedem Kommandozeilenprogramm nicht auf stdout ausgeben sondern auf stderr.
    git macht das auch brav und deshalb bekommst du das nicht mit, da du bei deinem Run-Aufruf lediglich $STDOUT_CHILD gesetzt hast.
    Also entweder $STDERR_CHILD setzen und den Stream noch mit StdErrRead() auslesen oder alternativ statt $STDOUT_CHILD $STDERR_MERGED setzen, dann sollte sich das auch über StdOutRead mit auslesen lassen.

    Ansonsten noch 3 Hinweise:

    • git ist kein Befehl der cmd.exe sondern ein eigenständiges Programm. Es ist daher unsinnig es erst indirekt über den Umweg @comspec & "/c " aufzurufen.
    • Ich empfehle um Probleme mit der Zeichenkodierung zu umgehen prinizpiell alles was von stdoutread kommt noch durch _WinAPI_OemToChar() zu schleifen.
    • Du musst StdOutRead() nicht unbedingt in einer Schleife ausführen. Es würde auch reichen den Prozess rödeln zu lassen und mit ProcessWaitClose() auf dessen Ende zu warten. Danach nur einmal StdOutRead() auf die Prozess-ID. Also so etwa:

    2 Mal editiert, zuletzt von AspirinJunkie (7. Februar 2024 um 13:03)

  • Hi AspirinJunkie 👋 ,

    ich nehme die Funktion gleich mal in meine Snippets mit auf, weil sie sehr hilfreich ist.
    Ich habe sowas bisher umständlicher gemacht, aber so geht es viel besser mit dem StdErr 👌 .
    Danke dafür.

    Ich empfehle um Probleme mit der Zeichenkodierung zu umgehen prinizpiell alles was von stdoutread kommt noch durch _WinAPI_OemToChar() zu schleifen.

    Das verstehe ich, habe aber bei den Tests dazu bisher keinen Unterschied gemerkt ob ich StdoutRead durchschleife oder nicht 🤔 .

    BugFix Ich sehe es geht super voran mit der GIT-SciTE-Integration, feine Sache!

    Viele Grüße
    Sven

  • aber bei den Tests dazu bisher keinen Unterschied gemerkt ob ich StdoutRead durchschleife oder nicht 🤔 .

    Wenn keine Sonderzeichen vorkommen dann brauchst du es nicht.
    Mach mal ein dir in einem Ordner, welcher Dateien mit Umlauten im Namen enthält - StdOutRead versaut hierbei die Kodierung.

    In eine wiederverwendbare Funktion gehört sowas rein.

  • Danke, jedoch hatte ich genau dies getan (also neben weiteren Tests noch).
    Mein Problem war einfach das ich im falschen Verzeichnis war, was ich nicht gleich erkannt hatte 🙄 .

    Jetzt nach deinem Hinweis und dem erneuten Versuch ist es mir aufgefallen und der Unterschied zu den Umlauten nun mit _WinAPI_OemToChar() auch 👌 .
    Danke dir.

    Viele Grüße
    Sven

  • Und Fehler sollten eigentlich von jedem Kommandozeilenprogramm nicht auf stdout ausgeben sondern auf stderr.

    :Face:Es ist ja nicht so, dass mir das neu wäre. Aber es gibt so Tage... :whistling:

    git ist kein Befehl der cmd.exe sondern ein eigenständiges Programm. Es ist daher unsinnig es erst indirekt über den Umweg @comspec & "/c " aufzurufen.

    War meinem C&P geschuldet, da ich die CmdLineRead-Funktion schon hatte. Aber klar, ohne Zweifel unsinnig.

    Du musst StdOutRead() nicht unbedingt in einer Schleife ausführen. Es würde auch reichen den Prozess rödeln zu lassen und mit ProcessWaitClose() auf dessen Ende zu warten. Danach nur einmal StdOutRead() auf die Prozess-ID.

    Passt. ;)

  • BugFix 7. Februar 2024 um 17:52

    Hat das Label von [ offen ] auf [ gelöst ] geändert.