2010-10-02 14 views
8

To pytanie było zadawane więcej niż jeden raz, ale nie znalazłem zadowalającej odpowiedzi w żadnej z tych dyskusji.Jak wyłączyć buforowanie wyjściowe w Process.StandardOutput

Uruchamiam proces wiersza polecenia, który generuje pomiar w czasie rzeczywistym do STDOUT, co daje nowy wynik mniej więcej co sekundę. Używanie System.Diagnostics.Process.StandardOutput powoduje całkowite niedopuszczalne opóźnienie (ponad 20 sekund), ponieważ dane STDOUT działają poprzez bufor 4k w Process.StandardOutput StreamReader i nie wydaje się, aby można było obejść ten problem.

Wywołanie Process.StandardOutput.BaseStream.Flush() nie działa.

Próbowałem już synchronizować bajt po bajcie Process.StandardOutput, ale nadal jestem 4k za rzeczywiste wyjście.

Czy ktoś może przynajmniej zweryfikować dla mnie, że możliwe jest jakoś pokonanie wszystkich problemów z buforowaniem, które mam z przekierowaniem STDOUT, i otrzymanie danych w mojej aplikacji, jak tylko pojawi się ona w oknie powłoki? Czy mogę dziedziczyć z klasy Proces i zmieniać sposób działania czytnika strumienia StandardOutput? Czy muszę przeglądać surowe połączenia WINAPI?

W jakiś sposób musi to być zrobione, nawet jeśli skończę pisać niezarządzanego C++, aby uruchomić zadanie i pochłonąć dane wyjściowe i połączyć je. Każda pomoc jest doceniana; Jestem na końcu mojego dowcipu ...

Edycja: Wydaje się, że potrzebuję implementacji .Net bibliotek "oczekiwać", które są dostępne dla C/C++, Perl, Python i Java (są to jedyne, które znalazłem do tej pory). Czy ktoś wie, czy taka bestia istnieje?

+0

ssie, że nigdy nie dostałeś dobrej odpowiedzi na to pytanie ... –

+0

Tak. W końcu uzyskałem kod źródłowy do zewnętrznego polecenia i zrekompilowałem je z wyraźnym spłukiwaniem bufora STDOUT. Nadal jednak chciałbym rozwiązać pierwotny problem. Sam bawiłem się przy pisaniu implementacji .Net Expect, ale rekompilacja zewnętrznego narzędzia wydawała się lepszym sposobem na uniknięcie sytuacji, w której mój szef krzyczał na mnie. –

+0

Zmagałem się z tym samym problemem. Czytam dane wyjściowe konsoli w osobnym wątku (lub właściwie 2: 1 dla stderr, 1 dla stdout). Jak się okazuje, StandardOutput buforuje tylko wtedy, gdy używasz wywołań takich jak 'Peek', które zwrócą -1 w procesie. Jeśli po prostu użyjesz 'ReadLine' lub' Read' z 1 bajtem, będzie działało dobrze i nie będziesz miał problemów z buforowaniem. – atlaste

Odpowiedz

1

"[Czy] istnieje sposób, aby go uruchomić tak, że nie zdaje sobie sprawy, że jest przekierowywany?" TAK: to jest właśnie domena Oczekiwania. Nie znam żadnej implementacji .Net; to na pewno możliwe, ale ...

+0

Bardzo trudne ze względu na sposób, w jaki system Windows działa wewnętrznie! (Cóż, nie z Mono na Unixie, gdzie masz dostęp do prawdziwych wirtualnych terminali, ale to już inna historia.) Oczekuj, że system Windows użyje jakiegoś funky trybu debugowania, aby wszystko działało, a AIUI było naprawdę grubym hackerem. Prawdopodobnie byłoby łatwiej użyć rzeczywistego 'oczekiwać' samego (uruchamiając skrypt' unbuffer') w podprocesie; tak, sprawia, że ​​wdrażanie jest trudniejsze, ale * ma * naprawdę duże szanse na działanie. Z wyjątkiem 'telnet.exe'; to szczególny (i wyjątkowo podenerwowany) przypadek. –

Powiązane problemy