Заставить CreateProcess наследовать консоль вызывающего процесса
Когда я вызываю CreateProcess в Windows, новый процесс не наследует консоль вызывающего процесса. Я сделал тестовую программу, которая запускает «ruby xtest», где xtest - это сценарий, который выводит «hello» на стандартный вывод. Я запустил эту тестовую программу из Emacs и не получил результата. Я также попробовал следующий код, вызывающий GetStdHandle, но опять же без вывода. Затем я попытался передать CREATE_NEW_CONSOLE в dwCreationFlags в CreateProcess, что создало целое новое окно с выводом Ruby. Наконец, я сделал простой fork / exec test и скомпилировал ее с помощью Cygwin's GCC. Эта программа работала: результат Ruby появился в Emacs, как и ожидалось. Я попытался расшифровать исходный код Cygwin в http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/spawn.cc?rev=1.268&content-type=text/x-cvsweb-markup&cvsroot=src, но не смог. Итак, как сделать так, чтобы новый процесс унаследовал консоль родительского процесса, чтобы выходные данные дочернего процесса отображались так, как ожидалось?
STARTUPINFO si;
PROCESS_INFORMATION pi;
memset(&si, 0, sizeof(si));
memset(&pi, 0, sizeof(pi));
si.dwFlags |= STARTF_USESTDHANDLES;
si.hStdInput = GetStdHandle(STD_INPUT_HANDLE);
si.hStdOutput = GetStdHandle(STD_OUTPUT_HANDLE);
si.hStdError = GetStdHandle(STD_ERROR_HANDLE);
if (!CreateProcess(0, "ruby xtest", 0, 0, 1, 0, 0, 0, &si, &pi)) die("CreateProcess");
Ответы 4
Я сделал это, передав каналы для hStdInput, hStdOutput и hStdError и вручную направив данные из каналов hStdOutput и hStdError в консоль.
Не уверен, что Debeige когда-либо решил это, но мне нужно было то же самое, но запуск другого потока для прослушивания вывода stdout, просто чтобы поместить его на stdout, казался мне безумным.
Следующее работает для меня и немного отличается от того, что он изначально опубликовал. Сначала я подумал, что это не сработает, если вы не установите si.cb, но когда я прокомментировал это в своем, он все еще работал, так что ... YMMV.
STARTUPINFO siStartInfo;
ZeroMemory( &siStartInfo, sizeof(STARTUPINFO) );
siStartInfo.cb = sizeof(STARTUPINFO);
siStartInfo.hStdError = GetStdHandle(STD_OUTPUT_HANDLE);
siStartInfo.hStdOutput = GetStdHandle(STD_OUTPUT_HANDLE);
siStartInfo.hStdInput = g_hChildStd_IN_Rd; // my outgoing pipe
siStartInfo.dwFlags |= STARTF_USESTDHANDLES;
// Create the child process.
bSuccess = CreateProcess(
NULL,
szCmdline,
NULL,
NULL,
TRUE,
0,
NULL,
NULL,
&siStartInfo,
&piProcInfo);
Согласно документации Microsoft, lpCommandLine (2. параметр):
The Unicode version of this function, CreateProcessW, can modify the contents of this string. Therefore, this parameter cannot be a pointer to read-only memory (such as a const variable or a literal string). If this parameter is a constant string, the function may cause an access violation.
Когда я перестал использовать здесь константу, у меня это сработало. Мне не нужны были STARTF_USESTDHANDLES и GetStdHandle.
Этот код из консоли prg запускается и выводит другой консольный exe в той же консоли:
FillChar(SI, SizeOf(SI), 0);
SI.cb:=SizeOf(SI);
FillChar(PI, SizeOf(PI), 0);
if CreateProcess(nil, CmdLineVar, nil, nil, False, 0, nil, nil, SI, PI) then ...
Я знаю, что эта ветка довольно старая, однако я столкнулся с той же проблемой.
Как и в случае с TS, дескриптор консоли был унаследован и нормально работал под Cygwin, но не на консоли Windows. Вместо этого вывод на стандартный вывод не отображался и не сообщалось об ошибках. Унаследованные ручки Pipe по-прежнему работали нормально.
Мне потребовалось некоторое время, чтобы определить (теперь очевидную) проблему: CreateProcess () был вызван с CREATE_NO_WINDOW. Отбросив этот флаг, вывод на консоль в порядке. (Хотя, согласно коду TS, они никогда не устанавливали этот флаг в первую очередь.)
Надеюсь, это может быть полезно для людей, которые тоже наткнулись на эту тему, например, я.
Спасибо за это, это сэкономило мне оооочень много времени и проблем!
Лучше всего работает недокументированное значение 0 для флагов создания, как в приведенном примере. Работал, как ожидалось, при компиляции для Windows 7 (в режиме без UNICODE) как VS 2019, так и MSYS2 / MinGW gcc 9.1. Итак, если пример не удался ~ 11 лет назад, это могло быть связано с другим поведением API WIn32 для этого недокументированного случая.