Когда я использую zip, как я могу отображать общий прогресс, не заполняя командную строку?


25

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

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

Я попробовал опцию -q( --quiet) в сочетании с -dg( --display-globaldots), но это просто затопляет стандартный вывод несколькими строками точек и не дает никаких полезных указаний.

Я также попробовал, -qdgds 10mкак упоминалось в справочной странице, но получил тот же результат.

Затем я попытался -db( --display-bytes) и -dc( --display-counts), но, похоже, не существует глобального параметра, поэтому он снова печатает его для каждого имени файла.

Наконец, я попробовал это вместе с -qлайком -qdbdc, но это ничего не дает.

Как ни странно, я нашел страницу man на сайте info-zip, в которой упоминается опция -de( --display-est-to-go), которая должна «отображать приблизительное время завершения операции архивирования».

Это похоже на то, что я хочу, но проблема в том, что моя версия zipне имеет этой функции. Я использую Ubuntu 14.04.1 64bit, bash-4.3.30 (1) и zip-3.00. Согласно Википедии, это последний стабильный релиз zip.

На странице info-zip sourceforge есть неизданные бета-версии, но я бы не стал доверять свои данные бета-версии.


Записать вывод в файл и использовать его для предоставления информации высокого уровня tee. Перед запуском zip, сделайте общее количество файлов (с помощью lsили find -type f) и, пока он архивирует, прочитайте файл журнала на количество строк обработанных файлов, которые у него уже есть (с помощью grepдля просмотра правильных строк и wc -lдля строк считать), поэтому ваша информация высокого уровня будет отображать что-то вроде «234/76438 обработанных файлов»;
Водолей Сила

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

Я не знаю, можно ли использовать stdin при создании ZIP-файлов, но если с gzip все в порядке, вы можете сделать что-то вродеpv /path/to/file | gzip > /path/to/file.gz
DopeGhoti

Ответы:


11

zipможет сжимать данные в стандартный вывод. Следовательно, вы можете комбинировать его с другими инструментами, такими как pv:

zip -qr - [folder] | pv -bep -s $(du -bs [folder] | awk '{print $1}') > [file.zip]

Удалите один из -bepвариантов для вашего удобства.


Спасибо за это! Я делаю это на моем Mac (brew install pv, brew install coreutils и заменяю du на gdu).
Джефф

6

Если вы в порядке с использованием 7z:

7z a output.zip folder/

Это даст вам индикатор выполнения, как это:

Open archive: test.zip
--
Path = test.zip
Type = zip
Physical Size = 232039663

Scanning the drive:
3 folders, 2401 files, 238122225 bytes (228 MiB)

Updating archive: test.zip

Items to compress: 2404

 16% 279 U folder/file.txt  

2

Я успешно использовал следующее:

zip -r [target_zip] [folder_to_zip] 2>&1 | 
pv -lep -s $(ls -Rl1 [folder_to_zip] | egrep -c '^[-/]') > /dev/null

И это объясняется ниже:

zip -r [target_zip] [folder_to_zip] 2> & 1 |

Записать рекурсивно в [target_zip] файл [folder_to_zip], перенаправив stderr на стандартный вывод. Обратите внимание, что stderr будет содержать одну строку для каждого обрабатываемого файла и каталога .

pv -lep -s $ (ls -Ral1 [folder_to_zip] | egrep -c '^ [- /]')> / dev / null

передайте в pv строки с именами файлов, когда они выводятся из zip. PV работает в режиме строки (подсчет прогресса на основе количества строк и размера также зависит от количества ожидаемых строк - см. справочную страницу PV -l ).

Общий размер ожидаемых строк собирается путем рекурсивного перечисления (ls) [folder_to_zip] и подсчета строк, начинающихся с «-» или «d», то есть всех файлов и каталогов (помните, что каталоги перечислены, начиная с «/») .

Выше приведен точный процент выполнения, так как 100% достигается, когда все файлы и каталоги обработаны.

Проблема с ответом pedroapero состоит в том, что прогресс рассчитывается на основе количества обработанных (сжатых) байтов по отношению к общему количеству байтов для обработки (без сжатия). В результате процесс завершится на уровне около 30% (в зависимости от степени сжатия).

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.