Lorsque j'utilise zip, comment puis-je afficher la progression globale sans inonder la ligne de commande?


25

Une barre de progression de longueur fixe, un nombre de fichiers ou d'octets, ou mieux encore un minuteur indiquant le temps restant estimé serait idéal.

zipLe comportement standard semble être d'imprimer une ligne pour chaque fichier traité, mais je ne veux pas que cette information soit surchargée lorsque je zippe des milliers de fichiers. Je veux une estimation approximative du temps que cela va prendre.

J'ai essayé l' option -q( --quiet) en combinaison avec -dg( --display-globaldots) mais cela inonde simplement la sortie standard avec plusieurs lignes de points et ne donne aucune indication utile.

J'ai également essayé -qdgds 10mcomme mentionné dans la page de manuel, mais j'ai obtenu le même résultat.

J'ai ensuite essayé -db( --display-bytes) et -dc( --display-counts) mais il ne semble pas y avoir d'option globale, donc il l'imprime à nouveau pour chaque nom de fichier.

Enfin, je l'ai essayé avec -qlike -qdbdc, mais cela ne produit rien.

Curieusement, j'ai trouvé une page de manuel sur le site info-zip qui mentionne une option -de( --display-est-to-go) qui devrait "afficher une estimation du temps nécessaire pour terminer l'opération d'archivage".

Cela ressemble exactement à ce que je veux, mais le problème est que ma version de zipn'a pas cette fonctionnalité. J'utilise Ubuntu 14.04.1 64bit, bash-4.3.30 (1) et zip-3.00. Selon Wikipedia, il s'agit de la dernière version stable de zip.

Il existe des versions bêta inédites sur la page info-zip sourceforge, mais je préfère ne pas confier mes données à une version bêta.


Enregistrez la sortie dans un fichier et utilisez-la pour fournir des informations de haut niveau avec tee. Avant de démarrer zip, faites un compte total des fichiers (avec lsou find -type f) et pendant qu'il zippe, lisez le fichier journal pour le nombre de lignes de fichiers traités qu'il possède déjà (avec greppour les bonnes lignes à regarder et wc -lpour les lignes compte), donc vos informations de haut niveau afficheront quelque chose comme "234/76438 fichiers traités";
Aquarius Power

vous pouvez travailler le timing en considérant la taille totale des fichiers et en vérifiant la taille de ceux qui ont déjà été traités; mais ... même les fichiers de même taille prennent un temps différent à traiter, donc ce sera toujours une supposition sauvage ...
Aquarius Power

Je ne sais pas si vous pouvez utiliser stdin lors de la création de fichiers ZIP, mais si gzip est correct, vous pouvez faire quelque chose commepv /path/to/file | gzip > /path/to/file.gz
DopeGhoti

Réponses:


11

zippeut compresser les données en sortie standard. Par conséquent, vous pouvez le combiner avec d'autres outils comme pv:

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

Supprimez l'une des -bepoptions à votre convenance.


Merci pour cela! Je le fais sur mon mac (brew install pv, brew install coreutils, and replace du with gdu).
Jeff

6

Si vous êtes d'accord avec l'utilisation de 7z:

7z a output.zip folder/

Cela vous donnera une barre de progression comme celle-ci:

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

J'ai utilisé avec succès les éléments suivants:

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

Et cela est expliqué ci-dessous:

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

zip récursivement dans le fichier [target_zip] le [folder_to_zip] redirigeant stderr vers stdout. Notez que stderr contiendra une ligne pour chaque fichier et répertoire en cours de traitement.

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

canalisez en pv les lignes avec les noms de fichiers lors de leur sortie depuis zip. pv fonctionne en mode ligne (le comptage des progrès en fonction des lignes et de la taille est également en nombre de lignes à prévoir - voir l' option PV man page -l ).

La taille totale des lignes à attendre est collectée en listant récursivement (ls) le [dossier_à_zip] et en comptant les lignes commençant par '-' ou 'd' c'est-à-dire tous les fichiers et répertoires (rappelez-vous que les répertoires sont répertoriés en commençant par '/') .

Ce qui précède fournit un pourcentage d'achèvement précis car le 100% est atteint lorsque tous les fichiers et répertoires ont été traités.

Le problème avec la réponse de pedroapero est que la progression est calculée sur le nombre d'octets traités (compressés) sur le nombre total d'octets à traiter (non compressés). En conséquence, le processus se terminera à environ 30% (en fonction du taux de compression).

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.