 | | | | |
| Как переназначить StdOut в файл для консольной программы запускаемой по CreateProcess |
Полный текст материала
Другие публикации автора: Алексей Кузнецов
Цитата или краткий комментарий: | «... Хочу предложить 2 способа:
Простой, с использованием command.com /c имя_консольной_программы > имя_файла_куда_переназначить_StdOut
и С использованием Win API
...» |
Важно:- Страница предназначена для обсуждения материала, его содержания, полезности, соответствия действительности и так далее. Смысл не в разборке, а в приближении к истине :о) и пользе для всех.
- Любые другие сообщения или вопросы, а так же личные эмоции в адрес авторов и полемика, не относящаяся к теме обсуждаемого материала, будут удаляться без предупреждения авторов, дабы не мешать жителям нормально общаться.
- При голосовании учитывайте уровень, на который расчитан материал. "Интересность и полезность" имеет смысл оценивать относительно того, кому именно предназначался материал.
- Размер одного сообщений не должен превышать 5К. Если Вам нужно сказать больше, сделайте это за два раза. Или, что в данной ситуации правильнее, напишите свою статью.
Всегда легче осудить сделанное, нежели сделать самому. Поэтому, пожалуйста, соблюдайте правила Королевства и уважайте друг друга.
Добавить свое мнение.
| | | Содержит полезные и(или) интересные сведения | | [1] | 11 | 84.6% | | | | | Ничего особенно нового и интересного | | [2] | 2 | 15.4% | | | | | Написано неверно (обязательно укажите почему) | | [3] | 0 | 0% | |
Всего проголосовали: 13 | | | | Все понятно, материал читается легко | | [1] | 11 | 91.7% | | | | | Есть неясности в изложении | | [2] | 0 | 0% | | | | | Непонятно написано, трудно читается | | [3] | 1 | 8.3% | |
Всего проголосовали: 12 |
[Ввод/вывод (StdIn/StdOut)]
Отслеживать это обсуждение 
Всего сообщений: 1112-05-2011 04:13Спасибо за статью. Есть одна, но ОЧЕНЬ БОЛЬШАЯ мелочь :)
а именно: в третьем варианте флаг: bInheritHandle := true; касается ВСЕХ хендлов процесса. Т.е. сокеты, другие открытые файлы будут продублированы в дочернем процессе. Т.е. если вы хотите передать только некоторые хендлы, то надо использовать 2-й вариант.
Я потратил 2 дня чтобы понять почему мой процесс не освобождает сокет при закрытии. При чем система говорит, что сокет принадлежит системе (дочерний процесс даже близко не светиться). При закрытии дочернего процесса, сокет освобождается. Будьте бдительны...
Просьба к автору статьи, допиши комментарий об этом нюансе. Может кому-то это сэкономит пару часов отладки. |
|
07-04-2007 10:54Ни чего не понял (не читал) но понял что речь идет об этом:
winexec('Command >file.txt',SW_HIDE); |
|
03-10-2004 22:15Хм...как то странно:
Когда я запускаю проект из Delphi то способы 2.1 и 2.2 работают и сохраняют резултат в файл. Но когда я выполняю скомпелированный exe, то файл в который должен выводиться результат консольной программы пустой. Причём эта программа не относиться к тем что не удается переназначить и стандартными средствами 'ProgName.exe > StdOut.txt'.
как так??
|
|
26-03-2002 21:20Пользуясь материалом этой статьи я написал удобную функцию для
вызова дочерних процессов. Желающим могу прислать исходник. Вот
описание функции:
//==============================================================================
// WinExecAndWait
//
// Summary...... Выполняет внешнюю программу с ожиданием завершения
// Parameters...
// Path - выполняемая программа с параметрами
// Visibility - окно процесса SW_ константа
// IFile - файл для перенаправления StdInput. Если равен nil, то
// ввод не перенаправляется
// OFile,EFile - соответственно выходные файлы. Если OFile<>nil, а EFile=nil,
// тогда StdError перенаправляется в тот же файл, что и StdOutput
//
// Returns...... Код возврата запущенного процесса
// Exceptions... EWin32Error
// Description.. Запускает процесс используя функцию API CreateProcess. Функция
// ждёт завершения дочернего процесса. Есть возможность
// перенаправить ввод/вывод в файл. В случае каких-либо ошибок при
// вызове функций Win32 API выбрасывается исключение EWin32Error.
// Возвращает код возврата дочернего процесса.
//==============================================================================
function WinExecAndWait(Path: PChar; Visibility: Word; IFile,OFile,EFile : PChar): DWORD;
|
|
25-01-2002 10:36Действительно, некоторые программы ничего не выводят в файл.
Я полагаю это те, которые не испльзуют стандарные функции DOS для вывода текста (например программы на Pascal_е, написанные с использованием модуля CRT). Вывод от таких программ не удается переназначить и стандартными средствами 'ProgName.exe > StdOut.txt',
файл получается пустой.
Однако насколько проще ;-)
|
|
02-01-2002 18:47Сттья классная, но все же от некоторых программ используя метод 2.2 ничего не записывается в файл. Что очень странно.
Интересно, а как можно вывод сделать например в TMemo ?
Можете рассказать подробно? |
|
24-12-2001 14:16сообщение от автора материала Спасибо Юрию Зотову, я про такой способ не знал :(
Я вообще то НЕ СПЕЦИАЛИСТ по WinApi, просто вот мне понадобилось
скидывать в файл именно StdOut консольной проги, чтоя и сделал сначала
первым способом, потом вторым, и подумал, что есть еще такие же люди как и я которым это пригодится вот и набил статейку...
Кстати пока разбирался со вторым способом много чего узнал о WinApi
и оказалось что надо не только читать хелп описывающий какую-то функцию, но и рытться в нем использую поиск :) |
|
20-12-2001 21:07Денис затронул очень важную проблему. Я за нее брался несколько раз, но она что-то так и не сдвинулась с места :)
Суть в том, что при выводе StdOut в pipe во многих консольных приложениях данные в пайпе появляются только при завершении консольного процесса, либо каждые 3-4Кб вывода (если столько набирается). Проверить это можно с помощью команды netstat -an 1. В случае же, например, когда приложение выдало на stdout какой-то запрос и ждет ввода пользователя, мы этого не увидим и будем просто висеть в ожидании завершения процесса.
Не скажу, что я уж очень внимательно читал рекомендованный автором раздел Win32 API Help, но читал и пробовал кучу различных примеров из разных источников. Более того, от данной проблемы не избавлен даже коммерческий компонент TGUI2Console. Автор очень быстро припух от моих вопросов и исчез с горизонта в крайне удивленном состоянии :)
Кто что-нибудь слышал, видел, знает или о чем-либо догадывается по данному вопросу, убедительная просьба пролить свет :) |
|
20-12-2001 19:05Хорошая и, безусловно, полезная статья. Но почему так вычурно? Можно же использовать обычный способ создания наследуемого хэндла.
var
SA: TSecurityAttributes;
...
SA.nLength := SizeOf(SA);
SA.lpSecurityDescriptor := nil;
SA.bInheritHandle := True;
И теперь передаем четвертым параметром CreateFile адрес SA. Соответственно, никаких DuplicateHandle уже не нужно (что экономит ресурсы), вызов SetHandleInformation тоже ни к чему.
Этот способ работал под Win98 и под WinNT (да и почему бы ему не работать, если он стандартный?). Надо только добавить, что поле lpSecurityDescriptor поддерживается лишь линейкой NT, а Win9x его игнорируют. Но в данном случае это неважно. |
|
20-12-2001 09:26А слабо сделать, чтобы не в файл выводить, а своей программе в буфер, да не ждать при этом закрытия дочерней программы, а получать данные по мере их вывода дочерней программой?
Пробовал я так сделать, делал через Pipes, но только вот у некоторых программ (ftp.exe, например) так не получается - информация не поступает, а поступает только при закрытии. А вот через MS Terminal Service (из Win2K) получается. Как же так? |
|
19-12-2001 19:22'Рукоятка' - это прикольно, но не общепринятый термин. Слишком дословный перевод.
Некоторые технические термины лучше вообще не переводить. |
|
|
|
