LINUX.ORG.RU

язык С: запустить процесс и дождаться его завершения


0

0

Господа! У меня сл. проблема: необходимо в ходе выполнения программы (на языке С) запустить из нее дополнительный процесс (расчет с использованием строренней программы), дождаться его завершения и продолжить выполнение моей проги далее. Я не есть программер на С - жизнь заставляет :). exec() и прочие ее варианты не устраивают, т.к. они завкршают программу или может я не знаю как можно их под мои нужды заточить :). Так же нашел функцию spawn(). Вроде то, что надо, но компилятор говорит что он такой ф-и не знает (Red Hat 9, компилер его же). #include <iostream.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <stdio.h> #include <process.h> подключены эти модули, но spawn в них нету :(. Подскажите, пожалуйста, как мне решить эту проблему - запуск дочернего процесса и дожидание его завершения (который день страдаю :(). Заранее благодарен!

anonymous

Ответ на: комментарий от Onanim

system разбивает аргументы сам (вернее поручает это шеллу), это паршиво. Ну и вообще, чёрт его знает, что там шелл намутит. У меня бы очень сильно голова болела, если б я этим пользовался.

Гораздо проще написать обёртку над fork+exec+wait и ей пользоваться.

system(3) - однозначно зло. И нефиг тут совращать малолетних. :)

Teak ★★★★★
()
Ответ на: комментарий от Teak

> system разбивает аргументы сам (вернее поручает это шеллу), это паршиво.

Разбор командной строки шеллом может быть как недостатком, так и
наоборот - желаемым эффектом. Зависит от конкретного случая.

> system(3) - однозначно зло. И нефиг тут совращать малолетних. :)

system(3) - это просто функция. Зло совершается людьми, которые не
умеют ее готовить :-)))

HTH

Onanim
()
Ответ на: комментарий от Onanim

Если мне нужно разобрать что-то шеллом, так я и запущу скрипт, для него написанный. А если мне нужно, цитирую, "запустить процесс и дождаться его завершения", то я не буду связываться с шеллом, и просто запущу процесс и дождусь его завершения. :)

Teak ★★★★★
()
Ответ на: комментарий от Teak

> Если мне нужно разобрать что-то шеллом, так я и запущу скрипт, для
> него написанный. А если мне нужно, цитирую, "запустить процесс и
> дождаться его завершения", то я не буду связываться с шеллом, и просто
> запущу процесс и дождусь его завершения. :)
>

Да ради бога, я же не против fork/exec/wait. Мои возражения относились
к излишней категоричности по отношению к system(3).

Onanim
()
Ответ на: комментарий от Onanim

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

В общем, автор темы предупреждён. :)

Teak ★★★★★
()
Ответ на: комментарий от Teak

2Teak:

IMHO для новичка как раз однозначно лучше пользоваться именно system(), со всех точек зрения. Ее написАли умные дяди, которые все предусмотрели -- и запускаемая программа правильно отыщется, и скрипт правильно запустится, и зомби не расплодятся. А суицидные программы новички писАть не должны!

Die-Hard ★★★★★
()

>#include <iostream.h>

AFAIK с программе на Си этот файл не нужен никогда.

php-coder ★★★★★
()
Ответ на: комментарий от Die-Hard

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

Teak ★★★★★
()
Ответ на: комментарий от Teak

> Ну, мне правда трудновато так сходу придумать ситуацию, в которой эта функция была бы полезна. [...]

Сходу пришло в голову следующее: если формат вызываемой программы не распознаётся ядром. Например, необходимо выполнить скрипт Perl. Если использовать system(), то весь код уместится на одной строке. А на скольких строках уместится вариант fork+exec+wait?

ddo
()
Ответ на: комментарий от ddo

> Сходу пришло в голову следующее: если формат вызываемой программы не
> распознаётся ядром. Например, необходимо выполнить скрипт Perl.
> Если использовать system(), то весь код уместится на одной строке.
> А на скольких строках уместится вариант fork+exec+wait?
>

Хм... а в чем (в данном случае) отличие скрипта от бинарника?
Скрипт с корректной shebang line и executable правами замечательно
запустится при помощи exec.

Onanim
()
Ответ на: комментарий от ddo

> если формат вызываемой программы не распознаётся ядром.

Не вполне понял, что имеется в виду. Скрипты прекрасно запускаются именно ядром, execl("/tmp/script.pl", "script.pl", "arg1", NULL) запускает скрипт.

> А на скольких строках уместится вариант fork+exec+wait?

На стольких же, ибо это дело надо сделать одной функцией. Сама функция тоже будет строчек из пяти, не больше.

Teak ★★★★★
()
Ответ на: комментарий от Teak

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

system("FOO=bar /usr/bin/someprog"); system("/bin/ls -1 | wc -l > numfiles");

Ну и так далее.

Если человек умеет пользоваться шеллом - то он должен понимать опасности system(3).

anonymous
()
Ответ на: комментарий от anonymous

> Скрипт с корректной shebang line и executable правами замечательно запустится при помощи exec.

Да, ты прав.

> > А на скольких строках уместится вариант fork+exec+wait?

> На стольких же, ибо это дело надо сделать одной функцией. Сама функция тоже будет строчек из пяти, не больше.

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

> Во всяком случае безоговорочно рекомендовать её новичку в C точно не стоит.

Я думаю так: если функция system() устраивает, то надо пользоваться ею. Если необходимо получить бОльший контроль, тогда надо использовать fork+exec+wait. А в остальном у второго подхода нет неоспоримых преимуществ перед первым.

ddo
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.