Lorsque j'utilise Zip, comment puis-je afficher la progression globale sans inonder la ligne de commande?
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.
Le comportement standard de Zip semble être d'imprimer une ligne pour chaque fichier traité, mais je ne veux pas que ces informations soient surchargées lorsque je zippe des milliers de fichiers. Je veux une estimation approximative du temps que cela va prendre.
J'ai essayé le -q (--quiet) option en combinaison avec -dg (--display-globaldots) mais qui inonde simplement la sortie standard de plusieurs lignes de points et ne donne aucune indication utile.
J'ai aussi essayé -qdgds 10m comme mentionné dans la page de manuel, mais a 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 -q comme -qdbdc, mais cela ne produit rien.
Curieusement, j'ai trouvé une page de manuel sur le site info-Zip qui mentionne un -de (--display-est-to-go) option 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 Zip n'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.
Zip peut 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]
Retirez l'un des -bep options à votre convenance.
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
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 |
Compressez 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 de la progression en fonction des lignes et de la taille est également en nombre de lignes à prévoir - voir page de manuel PV -l option ).
La taille totale des lignes à attendre est collectée en listant récursivement (ls) le [folder_to_Zip] et en comptant les lignes commençant par '-' ou 'd' c'est-à-dire tous les fichiers et répertoires (rappelez-vous 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).