LINUX.ORG.RU

Bash архивация

 , ,


1

3

Всем доброго времени суток.Никогда не писал bash скрипты. И тут потребовалось заархивировать кучу папок по отдельности. Есть папка History, в ней кучу папок с макетами и файлами. В ручную архивировать ну малость лень так как их более 100. Начал писать скриптец и тут началась ерунда. Если есть файлы кроме папок они тоже попадают в список. Вот код:

#!/bin/bash
echo "Архиватор каталогов"
cd /media/vol1tb/history
lsfolder="./*"
echo="Список каталогов:"
for search in $(ls -d $lsfolder)
do
echo "$search"
if [ "$1" = "" ]; then
  printf "Вы хотите заархивировать каталог  $search (y/n)? [y]: "
  read choose
else
  choose="$1"

fi

if [ "$choose" = "y" ]; then
  zip -r  "$search" "$search"
else
  printf "Пропускаем $search"
fi

echo ""

if [ "$2" = "" ]; then
  printf "Удалить каталог $search (y/n)? [n]: "
  read choose
else
  choose2="$2"
fi

if [ "$choose2" = "y" ]; then
  printf "Удаление $search"
  rm -r "$search"

else
 printf "Оставляем на месте"
fi
echo clear
echo "Архивация завершена"
done

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

И после архивации идет запрос на удаление каталога: ввожу y, все равно выдает что оставляет каталог на месте и не удаляет.

Вопрос подскажите как передать только список директорий без файлов в родительском каталоге.

И где я туплю по удалению


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

К сожалению, не встречал.

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

Кстати, упомяну ссылку http://www.nongnu.org/lzip/xz_inadequate.html

Однако, спасибо. Нет, раньше не читал, только слышал пересказ.

Zmicier ★★★★★
()
Последнее исправление: Zmicier (всего исправлений: 1)
Ответ на: комментарий от vodz

Все что касается тара - не интересует, и не является показателем чего либо.

Тар распространился и существует только потому, что в нем удосужились реализовать-таки более-менее исчерпывающее хранение всей метаинформации с распространенных ФС в unix мире. Всё.

Как формат он очень ограничен, и его применение сейчас не целесообразно и вредно. У нас ленты? Ок, частный случай, подходит tar. Во всех остальных случаях предлагаемый таром последовательный доступ - это пессимизация чистой воды, и не приемлема по дефолту. И закрывать на это глаза на якобы маленьких файлах не надо, т.к. сегодня у тебя 20МБ в архиве, а завтра 200ГБ, и ты приплыл с этим таром.

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

Все что касается тара - не интересует ... У нас ленты?

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

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

Бла-бла. Неприемлемо... Пф. Неприемлимо — это когда если у вас недокачалось и вы с zip-ом вообще ничего толком сделать не можете. Потому что список файлов в конце и его нету. А перенос бинарников всегда обставлялся скриптом по их инсталляции начиная с рождения Unix. А в POSIX давно включены и ustar и pax.

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

Неприемлимо — это когда если у вас недокачалось и вы с zip-ом вообще ничего толком сделать не можете.

По хорошему, формат может и должен поддерживать восстановление без индекса, по остаточной информации. Собственно, tar. (то, о чем ты говоришь, а не recovery record, это отдельная плюшка, не о том речь) То, что никто его не развил до нормального состояния удручает. И удручают те, кто не видит этого бревна в глазу.

Ведь цимес в том, что «наполненные» командами tar статьи о всевозможных способах архивирования данных выстреливают как раз в самый неподходящий момент.

Люди применяют тар по дефолту, а потом оказывается проблематично с этим разбираться. Кроме многогигабайтного архива tar.gz у тебя ничего нет, и ты даже не можешь узнать его исходный размер. Например, распаковка его на 2 TB раздел завершается ошибкой после целого дня работы! Как вообще после этого можно серьезно относиться к tar и gz, что не позволяют элементарно обнаружить или вытащить задрипанный лог или данные из себя.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 2)
Ответ на: комментарий от Deleted

И удручают те, кто не видит этого бревна в глазу.

Которые в пример ставят zip, у которого индекс в конце. Ну да, ну да, соринка...

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

Может потому что эти «люди» хотят модно-молодёжно, то есть комбайн? Вот и получили GNU-расширение с gzip/lzma/чёрт_лысый сверху, не поддерживаемый исходным tar? Ах, плохо получилось? Ну вот вам zip - кушайте на здоровье. goto begin

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