Как я могу прочитать выходные данные процесса, которые не были сброшены?

Вас укусил тот факт, что буферизация для потоков, которые автоматически открываются в программе C, изменяется в зависимости от типа подключенного устройства.

Это немного странно. Одна из вещей, которые делают *nix приятными для игры (и которые отражены в стандартной библиотеке C), заключается в том, что процессы не очень заботятся о том, откуда они получают данные и куда они их записывают. Вы просто перенаправляете и перенаправляете на досуге, и обычно это подключается и работает, и довольно быстро.

Одно очевидное место, где это правило нарушается, — это взаимодействие; вы приводите хороший пример. Если выходные данные программы буферизованы блоками, вы не увидите их до тех пор, пока, возможно, не накопится 4 КБ данных или процесс не завершится.

Однако программа может определить, пишет ли она на терминал через isatty() (и, возможно, также с помощью других средств). Концептуально терминал включает в себя пользователя, предлагающего интерактивную программу. Код библиотеки, открывающий stdin и stdout, проверяет это и изменяет свою политику буферизации на line buffered: когда встречается новая строка, поток сбрасывается. Это идеально подходит для интерактивных линейно-ориентированных приложений. (Он не идеален для редактирования строки, как это делает bash, который полностью отключает буферизацию.)

справочная страница открытой группы для стандартного ввода довольно расплывчата в отношении буферизации в чтобы дать реализациям достаточную свободу действий, чтобы быть эффективной, но он говорит:

стандартный входной и стандартный выходные потоки полностью буферизуются тогда и только тогда, когда можно определить, что поток не относится к интерактивному устройству.

Вот что происходит с вашей программой: стандартная библиотека видит, что она работает «не в интерактивном режиме» (запись в канал), пытается быть умной и эффективной и включает буферизацию блоков. Запись новой строки больше не очищает вывод. Обычно это хорошо: представьте, что вы записываете двоичные данные, записывая на диск в среднем каждые 256 байт! Ужасный.

Примечательно, что между вами и, скажем, диском существует целый каскад буферов; после стандартной библиотеки C идут буферы операционной системы, а затем уже сам диск.

Теперь к вашей проблеме: буфер стандартной библиотеки, используемый для хранения символов, которые нужно записать, находится в пространстве памяти программы. Несмотря на внешний вид, данные еще не покинули вашу программу и, следовательно, недоступны (официально) для других программ. Я думаю, вам не повезло. Вы не одиноки: большинство интерактивных консольных программ будут работать плохо, если вы попытаетесь управлять ими через конвейеры.

ИМХО, это одна из наименее логичных частей буферизации ввода-вывода: она действует по-разному, когда направлена ​​на терминал, файл или канал. Если ввод-вывод направляется в файл или канал, он обычно буферизуется, это означает, что вывод фактически записывается только тогда, когда буфер заполнен или когда происходит явный сброс => это то, что вы видите, когда вы выполняете программу через popen.

Но когда ввод-вывод направляется на терминал, возникает особый случай: весь ожидающий вывод автоматически сбрасывается перед чтением с того же терминала. Этот особый случай необходим, чтобы интерактивные программы могли отображать подсказки перед чтением.

Плохо то, что если вы попытаетесь запустить интерактивное приложение через каналы, вы проиграете: подсказки можно прочитать только тогда, когда приложение завершится или когда будет выведено достаточно текста, чтобы заполнить буфер. Вот почему разработчики Unix изобрели так называемые псевдотерминалы (pty). Они реализованы как драйверы терминала, так что приложение использует интерактивную буферизацию, но на самом деле вводом-выводом управляет другая программа, владеющая главной частью pty.

К сожалению, поскольку вы пишете application.exe, я предполагаю, что вы используете Windows, и я не знаю эквивалентного механизма в Windows API. Вызываемый объект должен использовать небуферизованный ввод-вывод (по умолчанию stderr не буферизован), чтобы вызывающая сторона могла прочитать подсказки перед отправкой ответа.

Проблемы моего вопроса в моем исходном сообщении уже очень хорошо объяснены в других ответах.
Консольные приложения используют функцию с именем isatty(), чтобы определить, подключен ли их обработчик stdout к каналу или реальной консоли. В случае канала весь вывод буферизуется и сбрасывается по частям, за исключением случаев, когда вы напрямую вызываете fflush(). В случае реальной консоли вывод не буферизуется и напрямую выводится на вывод консоли.
В Linux вы можете использовать openpty() для создания псевдотерминала и создания в нем вашего процесса. В результате процесс будет думать, что он работает в реальном терминале и использует небуферизованный вывод.
Кажется, в Windows нет такой возможности.

После долгих копаний в документации по winapi я обнаружил, что это < strong>неправда. На самом деле вы можете создать свой собственный экранный буфер консоли и использовать его для stdout вашего процесса, который тогда не будет буферизован.
К сожалению, это не очень удобное решение, потому что нет обработчика событий, и нам нужно опрашивать новые данные. Кроме того, на данный момент я не уверен, как справиться с прокруткой, когда этот экранный буфер заполнен.
Но даже если некоторые проблемы все еще остаются, я думаю, что создал очень полезную (и интересную) отправную точку для тех из вас. кто когда-либо хотел получить небуферизованный (и не очищенный) вывод процесса консоли Windows.

#include <windows.h>
#include <stdio.h>

int main(int argc, char* argv[])
{
    char cmdline[] = "application.exe"; // process command
    HANDLE scrBuff;                     // our virtual screen buffer
    CONSOLE_SCREEN_BUFFER_INFO scrBuffInfo; // state of the screen buffer
                                            // like actual cursor position
    COORD scrBuffSize = {80, 25};       // size in chars of our screen buffer
    SECURITY_ATTRIBUTES sa;             // security attributes
    PROCESS_INFORMATION procInfo;       // process information
    STARTUPINFO startInfo;              // process start parameters
    DWORD procExitCode;                 // state of process (still alive)
    DWORD NumberOfCharsWritten;         // output of fill screen buffer func
    COORD pos = {0, 0};                 // scr buff pos of data we have consumed
    bool quit = false;                  // flag for reading loop

    // 1) Create a screen buffer, set size and clear

    sa.nLength = sizeof(sa);
    scrBuff = CreateConsoleScreenBuffer( GENERIC_READ | GENERIC_WRITE,
                                         FILE_SHARE_READ | FILE_SHARE_WRITE,
                                         &sa, CONSOLE_TEXTMODE_BUFFER, NULL);
    SetConsoleScreenBufferSize(scrBuff, scrBuffSize);
    // clear the screen buffer
    FillConsoleOutputCharacter(scrBuff, '\0', scrBuffSize.X * scrBuffSize.Y,
                               pos, &NumberOfCharsWritten);

    // 2) Create and start a process
    //      [using our screen buffer as stdout]

    ZeroMemory(&procInfo, sizeof(PROCESS_INFORMATION));
    ZeroMemory(&startInfo, sizeof(STARTUPINFO));
    startInfo.cb = sizeof(STARTUPINFO);
    startInfo.hStdOutput = scrBuff;
    startInfo.hStdError = GetStdHandle(STD_ERROR_HANDLE);
    startInfo.hStdInput = GetStdHandle(STD_INPUT_HANDLE);
    startInfo.dwFlags |= STARTF_USESTDHANDLES;
    CreateProcess(NULL, cmdline, NULL, NULL, FALSE,
                  0, NULL, NULL, &startInfo, &procInfo);    
    CloseHandle(procInfo.hThread);

    // 3) Read from our screen buffer while process is alive

    while(!quit)
    {
        // check if process is still alive or we could quit reading
        GetExitCodeProcess(procInfo.hProcess, &procExitCode);
        if(procExitCode != STILL_ACTIVE) quit = true;

        // get actual state of screen buffer
        GetConsoleScreenBufferInfo(scrBuff, &scrBuffInfo);

        // check if screen buffer cursor moved since
        // last time means new output was written
        if (pos.X != scrBuffInfo.dwCursorPosition.X ||
            pos.Y != scrBuffInfo.dwCursorPosition.Y)            
        {
            // Get new content of screen buffer
            //  [ calc len from pos to cursor pos: 
            //    (curY - posY) * lineWidth + (curX - posX) ]
            DWORD len =  (scrBuffInfo.dwCursorPosition.Y - pos.Y)
                        * scrBuffInfo.dwSize.X 
                        +(scrBuffInfo.dwCursorPosition.X - pos.X);
            char buffer[len];
            ReadConsoleOutputCharacter(scrBuff, buffer, len, pos, &len);

            // Print new content
            // [ there is no newline, unused space is filled with '\0'
            //   so we read char by char and if it is '\0' we do 
            //   new line and forward to next real char ]
            for(int i = 0; i < len; i++)
            {
                if(buffer[i] != '\0') printf("%c",buffer[i]);
                else
                {
                    printf("\n");
                    while((i + 1) < len && buffer[i + 1] == '\0')i++;
                }
            }

            // Save new position of already consumed data
            pos = scrBuffInfo.dwCursorPosition;
        }
        // no new output so sleep a bit before next check
        else Sleep(100);
    }

    // 4) Cleanup and end

    CloseHandle(scrBuff);   
    CloseHandle(procInfo.hProcess);
    return 0;
}

Вы не можете. Потому что еще не сброшенные данные принадлежат самой программе.

Я думаю, вы можете сбросить данные в stderr или инкапсулировать функцию fgetc и fungetc, чтобы не повредить поток, или использовать system("application.ext >>log"), а затем mmap записывать в память, чтобы делать то, что вы хотите.