Есть ли недостатки в использовании вызовов system () вместо функций вашего языка программирования?

В конце концов, в системе Linux почти все в какой-то момент вызывают функции C.

Чтобы коснуться некоторых аргументов в комментариях, а также моих собственных мыслей:

1. Выполнение команд оболочки из программы c, особенно при использовании аргументов пользователя, является потенциальной уязвимостью. Например, если вы разрешили пользователю вызывать вашу программу с аргументом «foo; rm -rf *»; в зависимости от того, как вы вызываете оболочку, есть вероятность, что вы могли бы эффективно вызвать «mkdir foo; rm -rf *», если вы хотите сделать каталог, предоставленный пользователем. Это может быть или не иметь большого значения в зависимости от того, насколько вы доверяете своим пользователям и т. Д.
2. Выполнение команд оболочки приводит к потенциальным состояниям гонки, которых вы не можете избежать, с которыми можно было бы легче справиться, используя прямые системные вызовы, которые вы объединяете в цепочку.
3. Анализ вывода команд означает работу с большим количеством строковых операций в C, что менее чем забавно.
4. Если вы действительно предпочитаете bash, лучше всего, вероятно, реализовать небольшие программы, которые обертывают отдельные части C API вашей целевой библиотеки. В любом случае, это путь UNIX (tm).

ИЗМЕНИТЬ, чтобы ответить на комментарий Pimgd: обратите внимание, что условия гонки - это головная боль, и многие из них не обязательно являются проблемой для вашего конкретного варианта использования, но, по крайней мере, их стоит учитывать при взвешивании за / против. В любом случае, конкретные экземпляры состояния гонки, о которых я думал, включают (и, вероятно, есть другие классы):

1. Условия гонки типа безопасности. Если вы создаете временный файл, содержащий набор команд, а затем выполняете его, существует вероятность, что между созданием и выполнением кто-то войдет и изменит файл. (На самом деле существует множество вариантов этой темы для таких вещей, как установка / сброс символьных ссылок и т. Д.). Судя по вашим комментариям, это в значительной степени выходит за рамки вашего проекта, но это то, о чем следует знать для других приложений.

2. Условия многопроцессорной гонки. Самый простой пример, который я могу придумать, - это то, что происходит, если два экземпляра вашей программы хотят установить файл конфигурации и работают одновременно. Существуют определенные вызовы ОС, которые имеют определенные уровни гарантии атомарности, но вы теряете большую часть этого, если вызываете серию команд оболочки для записи в файл. (обратите внимание, что даже если вы делаете это из монолитного приложения C, а не из серии команд оболочки, вам все равно нужно будет сделать что-то дополнительное, чтобы экземпляр 1 не перезаписал изменение экземпляра 2, но вы, по крайней мере, вряд ли столкнетесь с В случае, если в результате вы столкнетесь с смешанными изменениями. В качестве примера рассмотрим:

   ФАЙЛ * fp = fopen ("config.txt", "wt");

   fprintf (fp, «Значение конфигурации 1:% s», config [0]);

   fprintf (fp, «Значение конфигурации 2:% s», config [1]);

   fflush (fp);

   fclose (fp);

vs.

system("echo Config value 1: `df | awk '{print $1}'` > config.txt");
system("echo Config value 2: `ps | grep foo | awk '{print $2}'` >> config.txt");

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

Минусы:

1. это небезопасно, если есть ввод пользователя
2. трудно разобрать вывод
3. он будет полагаться на что-то внешнее, например сценарий оболочки.
4. тяжелый процесс - system fork () и запустить другую программу параллельно

Плюсы:

1. легко реализовать
2. в зависимости от вывода программы синтаксический анализ может быть очень простым. пример system("ls -1");

Суммировать -

Все зависит от того, что вам нужно делать, но в общем случае отрицательных моментов больше, чем положительных.

Даже если он будет работать в Linux, вы не можете полагаться на доступность всех команд, которые собираетесь использовать, поэтому обратная сторона очевидна: вы не можете полагаться на доступность данного инструмента .