С++ - выполнить что-то в консоли.

system(), popen(), fork()/exec() - в порядке возрастания сложности

Tar же в ядро зашит?

В BIOS. В новых компьютерах в EFI.

Tar же в ядро зашит

Да, нынче пошли очень крутые разработчики. В какое ещё ядро? tar это тулза такая, отдельный бинарик.

Tar же в ядро зашит?

https://ru.wikipedia.org/wiki/Tar

у всех ли дистрибутивов из коробки идёт tar?

Для начала прочитайте это слово наоборот. После этого подумайте, - оно вам надо?

Очень смешно.

После этого подумайте, - оно вам надо?

Да, оно надо.

Нужно реализовать доставку патчей.

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

На сервере Ubuntu, что будет на стороне клиента - неизвестно.

При этом используем unix socket + tar.

Выполнение разорхивации будет от пользователя, от которого будет запущено приложение - и это точно не рут.

tar вроде никаких подтверждений не запрашивает, а это плюс.

Путь, по которому будем располагать архив и распаковывать его - неизвестен. Будет что-то вида: /*/user_name/*/test/test.tar

Не делай так. Это говнокод.

используй libarchive: https://github.com/libarchive/libarchive/wiki/Examples

А обёртка на C++ есть?

Попробуйте git или mercurial, - патчи доставлять вроде умеют.

Попробуйте git или mercurial, - патчи доставлять вроде умеют.

Увы, но невозможно.

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

QProcess

Тред не читал, но вместо system(«tar -xf») тебе нужно использовать libarchive, у которой есть поддержка нужного тебе формата. И она не так сложна в использовании, как кажется на первый вгляд. Глядя на примеры на гитхабе можно запросто разобраться, как ей пользоваться.

Удваиваю.

чем в данном случаи использование libarchive будет лучше распаковки new_ver.tar.gz ?

unix socket

ну что тут ещё добавить, зато про libarchive все знают.

Говнокод - тащить в проект библиотеку-велосипед вместо того, чтобы юниксвейно использовать проверенный временем инструмент.

юниксвейно использовать проверенный временем инструмент.

А если демону запрещён транзишн в bin_t (проще говоря, ничего нельзя запускать)? Или лимиты выставлены так что запустить не хватит сил. Или кто-то положит в начало PATH свой одноимённый tar, который нужное не умеет и/или наоборот, делает плохие вещи. Или нет места на временные файлы. Или их нельзя писать. (инбифо: разрешить bin_t, убавить лимиты, захардкодить путь, забандлить свою копию tar, найти место, разрешить писать)

вместо того, чтобы в соответствии с карго культом использовать проверенный временем идол

Не интересно.

Tar же в ядро зашит?

Да, прямо в земное ядро вшили.

Если администратор системы запретил обновлятору что-то обновлять, то мы обновлять не будем. Если администратор положил в систему свой тар, то и демона-обновлятора он тоже может поменять.

Я не вижу причин усложнять систему лишним кодом, это снижение безопасности и надёжности без профитов и с лишней работой.

При этом используем unix socket

И как же ты собрался с удалённым сервером взаимодействовать через unix-сокеты, локальные для машины?

Впрочем, вполне возможно, что в ядре, в которое вшит tar, и unix-сокеты умеют работать по сети.

По сабжу: судя по всему, тебе не нужна консоль, а нужно передать управление в tar, после чего дождаться его завершения. Для этого обычно используют fork+exec+wait.

Я не вижу причин усложнять систему лишним кодом, это снижение безопасности и надёжности без профитов и с лишней работой.

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

Вот если такой роскоши действительно нет или выходит тормозно, тогда и надо заморачиваться с libarchive, иначе это преждевременная оптимизация

Ну так для quick&dirty я и самый первый бы tar воткнул. Но уж никак не под соусом Ъ юниксвейности решения, к которому и была придирка.

Это не quick&dirty, это наилучшее решение в границах своей применимости

дурак что ле?

Да, прямо в земное ядро вшили.

Давайте без шуток, не актуально. Очевидно, что знать «всё» - невозможно.

Ограничение на запуск программ из произвольной программы на тюринг-полном языке - это абсурд.

Раз тема до сих пор не отмечена как решённая, напишу уже данный ответ явно:

#include <stdlib.h>

int main()
{
        return system("tar -xf test.tar.gz");
}

На си++ будет так же.

Второй вопрос - о стандартности tar:

[root@battlehummer ~]# rpm -e --test tar
ошибка: Неудовлетворенные зависимости:
        /bin/tar нужен для (установлен)redhat-lsb-core-4.1-33.fc24.x86_64

И как же ты собрался с удалённым сервером взаимодействовать через unix-сокеты, локальные для машины?

man netcat