Отсутствует конвейерный вывод из подпроцесса консоли в основной программе (Pari/GP,cygwin?)
У меня есть пользовательский графический интерфейс (в Delphi 6, 32 бита) для математической консольной программы Pari/GP: я вызываю Pari / GP в невидимом окне подпроцесса и общаюсь по каналам STDIN и STDOUT, и насколько я может распознавать из исходного кода в Delphi для консоли-подпроцесса, а также STDERR.
С Pari / GP версии 2.2.11 до версии 2.4 или около того все работало нормально, и я определил начало и конец связи (которая является асинхронной) с подпроцессом, ожидая приглашения. Но начиная с версии 2.5 каналы больше не получают подсказку. Однако, когда я запускаю Pari / GP в cmd-окне, у меня появляется полный диалог, включая подсказку. (У меня Win7, 64-битная, но, похоже, это не актуально, поведение на виртуальной машине с XP, 32-битная же)
У меня нет исходного кода программного обеспечения Pari / GP, но одно вероятное существенное различие между версиями состоит в том, что более новые версии не имеют внешнего cygwin.dll с ними.
Q: это поведение уже известно, а также его причина? Известный обходной путь? Также подсказывает, что могло быть наиболее вероятными причинами.
Как и просили, немного больше фона. В Delphi-6 я использую процедуру "createconsoleprocess" (реализованную в Jedi-проекте), которая обеспечивает
writeln(<string>) к невидимому подпроцессу и двум немного отличающимся постоянным потокам, которые асинхронно ждут ответа через канал (я полагаю, stdout). Это все еще хорошо для всех версий. Но в старой версии при каждом ответе была Pari / GP
prompt (только некоторые символы, такие как Dos-подсказка в Dos-окне). добавлен к последней части ответа, чтобы я мог разобрать части ответа до prompt -symbol произошел и мог затем отобразить этот полный ответ как Pari/GP-output через список строк для пользователя.После версии Pari/GP 2.5 эта подсказка больше не возникает, поэтому, если я не внесу исправлений, пользователь будет бесконечно ждать завершения ответа Pari / GP. Это было невозможно для меня - будь то путем изменения флагов программного обеспечения для подсказок и эха, будь то хакерской заменой stdout от stderr в определении трубы - произвести подсказку. Сумасшедший: если я просто запускаю Pari / GP в отдельной windows-консоли через cmd, тогда появляется приглашение - как будто есть новый канал, который неизвестен createconsoleprocess но известно windows-os и приглашение отправляется через этот новый канал.
По-видимому, единственной, возможно, актуальной и видимой модификацией версий является то, что более старые версии имеют cygwin.dll с Pari / GP и более новыми версиями этого нет. Но я понятия не имею о секретах cygwin, несмотря на то, что я уже скачал немного документации ранее - но это просто не мой опыт...
Вот изображение, которое показывает принцип общения. Мы видим окно моего GUI, и у него есть подпроцесс Pari / GP, с которым он взаимодействует в фоновом режиме через STDIN/STDOUT-pipe, предоставляемый процедурой CreateConsoleProcess. 
У меня также есть точный инструмент отладки, который точно отображает поток струн по трубам. Просто в более новых версиях строка подсказки больше не добавляется в конце STDOUT-сообщений (и я также не могу найти ее через STDERR-связь), но в простом окне консоли cmd есть эта подсказка, поэтому она должна быть где угодно....
1 ответ
Кажется, проблема не в том, что некоторые известные cygwin-несовместимости и т. Д. Были важны, поэтому stackru, возможно, был не лучшим местом, чтобы задать этот вопрос, поэтому я закрываю дело здесь.
Результаты поиска: после просмотра c-источников Pari/GP-версий мне кажется, что я нашел причину. Я не смог найти write () (или обернул его вокруг), кроме как через stdout, так что идея, что они могли ввести другой / новый тип канала для приглашения, кажется недействительной.
Хотя я не знаком с языком c, мне кажется, что в критической процедуре для помещения результатов в выходной канал есть код для удаления ранее добавленной строки приглашения из выходной строки перед отправкой. Есть некоторые флаги, и если s и еще s вокруг этого, то, возможно, они определяют раньше, была ли программа запущена дос / windows-консолью (затем оставить строку приглашения) или каким-то другим процессом (затем удалить строка приглашения) - есть флаг isinteractive, который, помимо прочего, переключается в этом сегменте исходного кода.
Таким образом, вопрос о влиянии отсутствующего файла cygwin.dll, возможно, не имеет отношения к этому конкретному вопросу, за исключением того, что именно по этой причине флаг не был установлен...
Я постараюсь связаться с авторами программного обеспечения для конкретной помощи.