Использование system() VS Использование библиотек

Гореть в аду.
Замучаешься обрабатывать ошибки и вывод утилит через system(); нужно обязательно проверять есть ли утилита в системе. Проще как библиотеки использовать. + если память не изменяет то на каждый вызов system будет создаваться новый шелл. (+расход памяти,+время инициализации). В общем я б не стал так делать, если не скрипт пишу

Учетверяю этого оратора.

если коротко, то при system etc порождается новый процесс, а при использовании библиотеки в общем случае нет

вот, например, интересное сравнение для первого варианта : https://blog.famzah.net/2009/11/20/a-much-faster-popen-and-system-implementat...

За system()? Да.

Потому что эскейпить специальные символы в именах параметров и файлов правильно - это сложно. Велики шансы, что ваша программа в результате не будет поддерживать файлы с пробелами, знаками доллара и кавычками в именах. Погуглите «shell injection».

Хотите запускать процесс - хотя бы передавайте аргументы напрямую, а не через шелл.

Да, вопрос безопасности открытый, согласен.

А про использование памяти и CPU, как мне кажется, не критично. Или я ошибаюсь?

В то время, как все пользуются приложениями на Electron и запускают мини-утилиты на Java, экономить системный вызов только в момент отправки файла, как-то странно.

99.999% времени программа будет висеть в трее и ничего не делать...

тогда уж писать на bash иль на ином языке с более юзерфрендли интерфейсом чем фундаментально сложный и требовательный С
чё ресурсы-то экономить. зато как просто - быстренько накидал несколько строчек и в продакшен.

Вообще я сам против Electron и Java на каждый чих, по мне, так это злоупотребление пользовательскими ресурсами.

А экономия одного системного вызова пару раз в день, это на грани разумного. Может быть я ошибаюсь, и поэтому задал этот вопрос.

А Plain C просто интересен как язык, потому и он. Так бы выбрал какой нибудь Python, если хотел бы скорость разработки.

gui-шный фронтенд через popen, system, exec etc для консольного бэкенда - общая практика

А Plain C просто интересен как язык, потому и он.

Если таки умеете plain C, то компромисным вариантом будет не system/библиотеки, а fork+exec+wait. Это убережет вас от bash+эскейпинга, но даст возможность работать с сложными программами.

А Plain C просто интересен как язык, потому и он

Раз уж выбрал идеологически Си, то и пиши на Си, как на нем идеологически принято(не через system).

если хотел бы скорость разработки

Ну раз скорость разработки для тебя не так важна, тогда в чем вопрос вообще? Используй либу.

А с чего вообще у тебя появилась идея пользовать system? Какая в этом выгода? Потому что я могу придумать кучу недостатков этого способа, но при этом не вижу ни одного достоинства.

Ну раз скорость разработки для тебя не так важна, тогда в чем вопрос вообще? Используй либу.

Ты так говоришь, как будто для либы дольше разрабатывать. Если проверять возвращаемый результат у system то как бы не больше строк получилось, чем для libcurl.

Ну я это вижу примерно так: 1. Программа будет использоваться только на ПК с настроенным окружением (будет установлен cURL). 2. system() в одну строчку написать и отладить сильно проще, чем подтянуть либу и заиспользовать её. 3. Требуется обработка только базовых ошибок.

Просто хочу узнать, нормальное ли это решение в конкретных ситуациях.

А, ну вот как раз есть повод спросить у местных экспертов. Значит, есть научный софт (без гуя), юзер задаёт имя директории, куда будут складываться результаты вычислений.

Нужно создать эту директорию, если её ещё нет. Возможны пробелы в имени. Имя может быть вида «foo/bar/baz», и тогда все родительские директории тоже нужно создать.

Сейчас это делает такой код на C++

system(("mkdir -p + '" + path + "'").c_str())

Лаконично и понятно. Но !Ъ, так как system, да и c_str глаза режет (это единственное место, где вообще есть си-строки). Как бы переписать это место?

std::filesystem использовать не получится, так как на целевых машинах зачастую компиляторы без C++17.

system() не надо, разберись с popen() если хочется использовать C по сути как клей и GUI. Например cdebootstrap через popen() вызывает sha256sum для подсчёта хеша вместо использования библиотек и ничего, всё нормально. В идеале конечно использовать нативное API.

system только в том случае если ты просто для себя по бырому статичную команду вызываешь. Или тебе реально нужно сессию shell запустить.

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

«Одного системного вызова»? system потянет за собой сотню-тысячу. Конечно, для пары раз в день всё равно пофиг.

1. не является выгодой конкретного метода.
2. то есть написать system в одну строчку — это легко, а дернуть метод либы в одну строчку — это до фига как сложно?
3. обрабатывать или нет ошибки — это в любом случае твой выбор, какой бы метод ты не использовал. Если ты не хочешь их обрабатывать, никто тебя не заставит этого делать вне зависимости от способа вызова.

Все еще не вижу ни одного преимущества.

Ох, ну да, моя вина)

Нужно было уточнить, что не только system(), а любое решение из popen, system, exec... VS нативное API библиотеки.

Возможны пробелы в имени.

А одинарные кавычки? А знак доллара после одинарной кавычки?

Без зависимостей, очевидно, не обойтись, потому что в стандартной библиотеке работа с файлами и директориями минимальна. Один из вариантов - boost.

Что? fork + exec + fork + exec

Только в данном случае curl — это консольный фронтенд к libcurl.

А программы стартуют без сисколлов?

бэкенд обычно полнофункциональное по: утилита, демон или что.

а как выполнить libcurl?

бэкенд обычно полнофункциональное по

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

библиотеку cURL

Библиотека - правильный вариант. Какие могут быть сомнения?

Я не говорю, что дольше разрабатывать. Мой основной тезис: «Не используй system там, где можно использовать либу».

есть отдельный котёл в аду для тех, кто подгружает целый boost (либо другой крупный фреймворк) ради одной функции или советует кому то так делать

ваша мысль понятна, но библиотека не является бэкендом.

Например, никто не считает ангуляр или реакт бекендом для браузерного приложения. А fcgi между сервером и пхп - фронтендом серверного.

А вот интерфейс между клиентским интерфейсом в gui и командной строкой утилиты вполне можно охарактеризовать как фронтенд-бэкенд

Лаконично и понятно.

Говнокод с инъекцией.

Как бы переписать это место?

Разбить путь на компоненты и вызвать mkdir(3) в цикле. Для выдачи ошибок использовать исключение <system_error> и добавить перегруженную сигнатуру с аргументом error_code& для варианта без исключений.

Если тебе нꙋжно что҃то простое срочно сваѧть на коленке то через system() быстрее. Но это не будет работать если нужно что-то не такое уже и простое.

большинство библиотек boost это header only libs. И они друг с другом не связаны.

Говорить о том что boost это крупный фреймворк, это явно быть не в теме...

Например

sudo apt install libboost-atomic-dev

НОВЫЕ пакеты, которые будут установлены:
  libboost-atomic-dev
обновлено 0, установлено 1 новых пакетов, для удаления отмечено 0 пакетов, и 0 пакетов не обновлено.
Необходимо скачать 3 104 Б архивов.
После данной операции, объём занятого дискового пространства возрастёт на 10,2 kB.

10 кб. Очень крупный фреймворк...

убивать надо за такое. прямо не отходя от компа. у меня для таких случаев есть паяльник на 100 ватт.

почему?

можно подумать, например, IDE с компилятором как-то иначе дружат, и ведь никого еще паяльником не зажарили?

при чём тут IDE с компилятором? IDE - это просто оболочка для редактирования кода. компилятор в ней может быть использован любой и он НИКАК ВООБЩЕ к IDE не привязан. задача IDE - работа с кодом. компиляция - не задача IDE. так что это неадекватный пример.

а софт, который, простите, юзает банальный curl через system - за это надо убивать на месте.

Имей ввиду, что с popen/pipe тебе придется мутить асинхронный/nb io, в том случае, если идет много ввода и вывода в дочерний процесс. Например ты будешь write в stdin процесса, а процесс будет в это время write в stdout. Если не читать потихоньку его stdout, то вы рано или поздно deadlock (зависит от буфера в ядре).

По сабжу: если тебе много разного из юникса надо обернуть в gtk, то очевидно fork/exec, иначе ты освоишь половину всех библиотек и [хреново] перепишешь половину /usr/bin. В одной строке шелла больше мудрости, чем в 10к строк на си.

По поводу «парсить вывод = ад»: напиши под каждую оборачиваемую утилиту шелл-скрипт, который вернет итоги в едином удобном для сишки виде. Там можно будет и sed, и perl, и awk, и весь юникс.

Для просветления и контраста с местными идиологами можешь почитать исходники и трекер какого-нибудь unetbootin, например. Прям твой случай, один в один.

*идеологами, опечатка ненамеренная

не критично. Или я ошибаюсь?

Запуск группы процессов при отправке файла, ресайзе изображения, фильтрации лога, [раз]упаковке архива составляет 0,0x%.

Это самый адекватный пример, тащемта. Когда что-то сложное работает сообща с остальным сложным, решая сложную задачу, и не пилит ради этого сишкин велик.

Мир всю жизнь io-bound, но нет они всю жизнь считают такты, НТЖ?

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

«оболочка для редактирования кода» называется «редактор»

А так - некоторые проекты вообще собираются только в IDE ) Спросите про это у некоторых пользователей QtCreator, VS или того же Code::Blocks ;)

Преимущества использования библиотек понятны, но у system, exec, popen тоже есть свои области использования. Например, интерактивные интерфейсы для утилит, которые также должны использоваться в пакетном режиме из командной строки и т.п. В общем, не всегда это так категорически плохо, как вам кажется.

у Qt, например, есть спец. класс QProcess - для написания фронтендов к утилитам с командной строкой. Так что почему бы и нет?

Какой проект тебе не приведи, ты назовешь его говнокодом, потому что у тебя такое определение. Один успешный и удобный я уже привел. Искать их долго, снаружи не видно, что они внутри юзают. И не факт, что ты не права.

Давай объективно, в каком *конечном* итоге выражается неправильность сабжевого подхода? Критериями можно выбрать: простоту/ясность реализации, дальнейшую поддержку/изменяемость, бытовую латентность (не замерную в наносекундах, тут все ясно). Два для разработчика, один для юзера.

Мое мнение по exec/sh: ясность сильно выше (exec(do-curl.sh, -x, -y) вместо страницы-другой кода), поддержка тривиальная (добавить/заменить ключи, изменить регэкс), для юзера может быть небольшая задержка, если комп чем-то серьезным занят.

странно что такой вопрос вообще возник.

По идее надо обернуть https://linux.die.net/man/3/mkdir

https://techoverflow.net/2013/04/05/how-to-use-mkdir-from-sysstat-h/

Или заюзать жирно-boost: http://www.boost.org/doc/libs/1_51_0/libs/filesystem/doc/index.htm

Ну вот и получается, что

• либо надо завязываться Boost или C++17, что далеко не всегда возможно
• либо использовать небезопасный system
• либо вручную мудохаться с разбором пути, тогда получится портянка типа этой (и ещё не факт, что там все особые случаи учтены).

Еще можно сделать fork() || execl("/bin/mkdir", "mkdir", "-p", path.c_str(), nullptr); и никаких инъекций.

Неподъёмной сложности задача?

static void makePath(std::string path, mode_t mode = 0755)
{
    CXX_VALIDATE_ARG(!path.empty());

    if (path[path.size() - 1] != '/')
        path += '/';

    size_t pre = 0, pos = std::string::npos;
    while ((pos = path.find_first_of('/', pre)) != std::string::npos)
    {
        std::string dir = path.substr(0, pos++);
        pre             = pos;

        if (dir.size() == 0)
            continue;

        if ((::mkdir(dir.c_str(), mode) == -1) && errno != EEXIST)
            throw std::system_error{errno, std::generic_category()};
    }
}

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

я юзаю Code::Blocks уже лет десять, если не больше. и он спокойно экспортирует makefile'ы (а также кучу прочих форматов). и может также работать с кастомными makefile'ами. и импортировать какие-то другие форматы проектов (это я не юзаю). он работает с любыми компиляторами, я даже ассемблер на нём собирала и прошивки для микроконтроллеров. это именно удобный инструмент для работы с кодом, с кучей плагинов. и он никак вообще не привязан к компилятору и тулчейну. собственно, даже редактор кода в нём можно выбирать. проекты Code::Blocks прекрасно собираются и без него. и есть отдельные утилиты по экспортированию их во что угодно. никаких чудес в нём нет.

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

культя - это отдельная песня. они придумали велосипед с треугольными колёсами и на этом велосипеде невозможно ездить без специальных приспособ типа очень жёстко завязанного на его особенности IDE. но это ущербность самой культи. тот же wxWidgets спокойно позволяет писать проекты без всяких специальных IDE. потому что не обвешан жиром со всех сторон.

_некоторых_ пользователей, не всех.

понятно, что Code::Blocks умеет makefile и т.д.