system в общем случае лучше чем второй.

а нельзя ли вообще работу с архивом на шелл-скрипте не?

system в общем случае лучше чем второй.

и для уязвимостей раздолье

Можно, просто программа сама по себе смесь С + Bash + Python, а из-за одного места я не хотел сильно перегружать программу скриптами.

Что-то ничего не понятно на счёт второго способа. Хочешь завернуть вызов system() в «библиотеку» или заюзать какой-нибудь libtar?

Второе. Точнее, их хедеры, которые эта lib* закинет в /usr/include.

крис ты?

Первый метод гарантированно сделает свою работу в отдельном процессе который унесёт с собой все потенциальные негативные сайдэффекты от своей деятельности.

Второй вариант может быть реализоват по-разному, и как обёртка для system() с tar, и как библиотека с ф-иями. В обоих случаях это скорее всего будет хуже чем system(), т.к. либо создаст лишнюю зависимость на пустом месте, либо потенциально будет накапливать баги в основном процессе.

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

создаст лишнюю зависимость на пустом месте

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

То есть мне проще поступиться понятиями о красивости и писать system()? (Я не держусь за эти понятия, просто вопрос)

То есть мне проще поступиться понятиями о красивости и писать system()?

Проще - да, либу искать не надо.

Лучше - хз. Под вендой с таром возится придётся например.

Относительно качества кода лучше второй вариант. Есть явная зависимость от библиотеки tar (или что ты там будешь юзать).

Относительно произодительности — не спавнится лишний процесс, в отличие от вызова system.

это ты на аватарке?

первый способ юниксвейнее, tar присутствует почти везде и вообще вроде даже стандартом POSIX требуется

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

также в некоторых системах (соляра) бинарник может называться gtar

То есть мне проще поступиться понятиями о красивости и писать system()?

Какой-то странный вопрос, откуда постороним людям знать проще ли тебе поступиться с иррациональным чувством или нет. Я, например, так и непойму почему вдруг второй вариант «красивый», в топике совсем нет никаких намёков на возможные причины такого вывода. В инженерии «красивое» решение примерно которое решает задачу наиболее просто. Либа здесь выглядит как overengineering.

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

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

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

Кроме компилятора, который при компиляции не выдаст ошибки. Фэйл.

в какой системе, кроме windows, нет tar из коробки?

Это типичный подход быдлокодера. «Да эта библиотека есть на любой системе!». Зависимости нужно указывать всегда, если это не вендоподелка, которая тащит всё нужное с собой. Чтобы его программа собралась и заработала или выдала хотя бы осмысленную ошибку на любом самом экзотичным дистрибутиве из прошлого и далёкого будушего.

Выбирай второй вариант, ибо он наиболее идеалогически верный. Во всяком случае в софте не «для себя» такое точно предпочтительнее.

Зависимости нужно указывать всегда

ну вот в соответствующем месте и указывай (ебилде, deb, rpm), там всем зависимостям место, а на винде да, нужно тащить tar с собой

или выдала хотя бы осмысленную ошибку

что мешает выдавать эту осмысленную ошибку в первом варианте? Проверяем наличие tar, выдаём ошибку

ась?

дык использование system в коде для задачи управления файлами ( а лучше вообще какой нить внешний скрипт который(его исполнение) предшествует исполнению твоей числодробилки(которою главный скрипт и запускает)) и есть эталлоной крассивости решение в стиле юникса ,

посмотри на вике статью про автора sh Стивена Боурна и историю как шел постепенно стал полноценным языком программирования.

а вот стремление весь код опустить до С - это не здоровое и школовство.

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

В питоне tarfile в стандартной либе идет.

system("tar -xzvf /archive.tar.gz");

Ужас-то какой!

Ну так он не будет его таскать. Он будет вызывать функцию из библиотеки из системного пакета. Он же не статически линкует.

ты про абсолютный путь?

а на винде да, нужно тащить tar с собой

Программа GNU/Linux-only. По определенным причинам.

Я про вызов system()

Кроме компилятора, который при компиляции не выдаст ошибки. Фэйл.

Компилятор многое не узнает при компиляции. Например, не сможет оценить степень твоей упоротости.

Качественно сделать это одним из двух способов:

1) Хороший - использовать хедеры tar, прилинковать libtar, сделать обработчик эксепшенов, чеки на закоррапченый архив, права доступа в таргет директорию и т.д.

2) Приемлимый - так как твоя софтина всё равно сборная солянка из C++/Bash/Python, то какбэ она изначально несекурное и нестабильное нечто. Можно вынести вызов tar в bash-скрипт, который сам проверит всё на ошибки, сам распакует и сам напишет логи.

Я тут ради интереса посмотрел на своей гентушечке, оказывается libtar таки установлена, но использует её только vlc (интересно зачем?)

а как вместо?

Через библиотечные функции.

а не лучше ли вообще организовать приложение так , что бы не нужно было бы из с-кода делать разпаковку(последством вызова ли или непосредственно библиотечной функцией)?

Не думаю: если ты, скажем, хранишь какие-нибудь xml/json и т.п. объекты, да еще дофига, лучше их сразу же и зиповать для сбережения места.

А если у тебя что-то вроде структуры опенофиса, то и tar понадобится.

Без архива никак - там будут большие списки.

Ни то ни другое

первый вариант обещает сюрпризы со странными именами файлов, например «`rm -rf $HOME`.tar.gz». Второй не нужен. Правильно - вызывать внешнюю прогу, но без shell-ов(popenы/execи всякие).