Comment rediriger la sortie de wget en tant qu'entrée pour décompresser?


131

Je dois télécharger un fichier à partir de ce lien . Le téléchargement de fichier est un fichier zip que je devrai décompresser dans le dossier actuel.

Normalement, je le téléchargerais d'abord, puis lancerais la commande unzip.

$ wget http://www.vim.org/scripts/download_script.php?src_id=11834 -O temp.zip
$ unzip temp.zip

Mais de cette façon, je dois exécuter deux commandes, attendre la fin de la première pour exécuter la suivante, de plus, je dois connaître le nom du fichier temp.zipauquel le donner unzip.

Est-il possible de rediriger la sortie de wgetvers unzip? Quelque chose comme

$ unzip < `wget http://www.vim.org/scripts/download_script.php?src_id=11834`

Mais ça n'a pas marché.

bash:: wget http://www.vim.org/scripts/download_script.php?src_id=11834 -O temp.zipredirection ambiguë

En outre, a wgetété exécuté deux fois et téléchargé le fichier deux fois.


Dans ce dernier exemple, wget a probablement été exécuté deux fois car le? est un caractère spécial dans la coquille. Mettre l'URL dans "" devrait aider.
p-statique

Ce fil semble avoir une solution. Je n'ai pas essayé moi-même cependant. serverfault.com/questions/26474/…

Réponses:


96

Vous devez télécharger vos fichiers dans un fichier temporaire, car (en citant la page de manuel unzip):

Les archives lues à partir d'une entrée standard ne sont pas encore supportées, à l'exception de funzip (seul le premier membre de l'archive peut être extrait).

Il suffit de rassembler les commandes:

wget http://www.vim.org/scripts/download_script.php?src_id=11834 -O temp.zip; unzip temp.zip; rm temp.zip

Mais afin de le rendre plus flexible, vous devriez probablement le mettre dans un script afin de sauvegarder une frappe et pour vous assurer de ne pas écraser accidentellement quelque chose, vous pouvez utiliser la mktempcommande pour créer un nom de fichier sûr pour votre fichier temporaire:

#!/bin/bash
TMPFILE=`mktemp`
PWD=`pwd`
wget "$1" -O $TMPFILE
unzip -d $PWD $TMPFILE
rm $TMPFILE

Est-ce wget file.zip && unzip file.zipla même chose wget file.zip; unzip file.zipou est-ce que l'un est préféré à l'autre? Merci :)
jaggedsoft

7
@NextLocal n'exécutera wget && unziple décompression que si wget a réussi. wget ; unzipfonctionnera quand même unzip, pointant éventuellement sur un fichier inexistant.
Timoto

funzip était la réponse que je cherchais. Terraform (pour quelque raison que ce soit) le conditionne sous forme binaire sous la forme d’un fichier unique dans une archive zip, donc c’était parfait pour moi.
Asfand Qazi

75

Voici un extrait de ma réponse à une question similaire:

Le format de fichier ZIP comprend un répertoire (index) à la fin de l'archive. Ce répertoire indique où, dans l’archive, se trouve chaque fichier et permet ainsi un accès rapide et aléatoire, sans lire toute l’archive.

Cela semblerait poser un problème lors de la tentative de lecture d'une archive ZIP par un canal, dans la mesure où l'index n'est accessible qu'à la toute fin et que les membres individuels ne peuvent donc pas être extraits correctement avant la lecture complète du fichier et sa non disponibilité. . En tant que tel, il ne semble pas surprenant que la plupart des décompresseurs ZIP échouent simplement lorsque l'archive est fournie via un tube.

Le répertoire à la fin de l'archive n'est pas le seul emplacement où les méta-informations de fichier sont stockées dans l'archive. De plus, les entrées individuelles incluent également ces informations dans un en-tête de fichier local, à des fins de redondance.

Bien que tous les décompresseurs ZIP n'utilisent pas les en-têtes de fichiers locaux lorsque l'index n'est pas disponible, les versions de tar et cpio se terminant par libarchive (alias bsdtar et bsdcpio) peuvent et le feront lors de la lecture via un canal, ce qui signifie que:

wget -qO- http://example.org/file.zip | bsdtar -xvf-

1
C'est excellent! Je ferais remarquer que tar m'avertit que la taille des données non compressées est incorrecte (0 attendu), mais que les fichiers eux-mêmes ne semblent pas endommagés. Cela est dû au manque d’index.
Wyatt8740

1
J'ai un .zipfichier ici qui contient des fichiers avec des autorisations exécutables. Lorsque je télécharge et que je me connecte bsdtar, les bits d’exécution sont jetés. Lorsque je télécharge sur le disque et que j'extrais avec bsdtarou unzipensuite, les bits d'exécution sont respectés.
Golar Ramblar

//, @GolarRamblar, n'a-t-il jamais découvert pourquoi?
Nathan Basanese

1
@NathanBasanese: voici la réponse. En bref: une archive ZIP contient deux emplacements où stocker ces informations, ce qui peut être incohérent et selon que le fichier bsdtars'ouvre est consultable ou non, il utilise l'un ou l'autre endroit.
Golar Ramblar

20

Si vous avez le JDK installé, vous pouvez utiliser jar:

wget -qO- http://example.org/file.zip | jar xvf /dev/stdin

3
Je viens de trouver que jarcela ne préserve pas les autorisations de fichiers. Belle astuce sinon.
phunehehe

7
Vous n'avez pas besoin de donner un | jar xv
paramètre de

15

Je ne pense pas que vous vouliez même déranger la sortie de wget dans unzip.

Extrait de l'article wikipedia "ZIP (format de fichier)" :

Un fichier ZIP est identifié par la présence d'un répertoire central situé à la fin du fichier.

wget doit terminer complètement le téléchargement avant de pouvoir décompresser un fichier, il doit donc être exécuté de manière séquentielle et non imbriquée comme on pourrait le penser.


10

La syntaxe appropriée serait:

$ unzip <(curl -sL https://www.winpcap.org/archive/1.0-docs.zip)

mais cela ne fonctionnera pas, à cause de l'erreur ( Info-ZIP sur Debian ):

lseek(3, 0, SEEK_SET)                   = -1 ESPIPE (Illegal seek)

Archive:  /dev/fd/63
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of /dev/fd/63 or
        /dev/fd/63.zip, and cannot find /dev/fd/63.ZIP, period.

ou sur BSD / OS X:

Trying to read large file (> 2 GiB) without large file support

En effet, les outils de compression standard utilisent principalement des lseekfonctions afin de définir le décalage du fichier à la fin pour lire son enregistrement de fin de répertoire central . Il se trouve à la fin de la structure de l'archive et il est nécessaire de lire la liste des fichiers (voir: Structure du format de fichier Zip ). Par conséquent, le fichier ne peut pas être une FIFO, un canal, un périphérique terminal ou toute autre dynamique, car l'objet en entrée ne peut pas être positionné par la lseekfonction.

Donc, vous avez les solutions de contournement suivantes:

  • utiliser différents types de compression (par exemple tar.gz),
  • vous devez utiliser deux commandes distinctes,
  • utiliser des outils alternatifs (comme suggéré dans d'autres réponses),
  • créez un alias ou une fonction pour utiliser plusieurs commandes.

Je pense que cela pourrait encore être un FIFO. Il vous suffirait de continuer à lire à partir de la FIFO jusqu'à EOF (mise en mémoire tampon de toute la FIFO en mémoire ou dans un fichier temporaire). Totalement faisable pour faciliter la création de script, mais pas très utile.
Evan Carroll

8

Repost de ma réponse :

BusyBox unzippeut prendre stdin et extraire tous les fichiers.

wget -qO- http://downloads.wordpress.org/plugin/akismet.2.5.3.zip | busybox unzip -

Le tiret suivant unzipconsiste à utiliser stdin en tant qu'entrée.

Vous pouvez même,

cat file.zip | busybox unzip -

Mais c'est juste redondant de unzip file.zip.

Si votre distribution utilise BusyBox par défaut (par exemple, Alpine), lancez simplement unzip -.


Truc très utile, merci!
Brice

-1

Cela fonctionne très bien pour moi:

tar xvf <(curl -sL http://www.vim.org/scripts/download_script.php?src_id=11834)

jar xvf <(curl -sL http://www.vim.org/scripts/download_script.php?src_id=11834)

wget -qO- http://www.vim.org/scripts/download_script.php?src_id=11834 | tar xvf -

wget -qO- http://www.vim.org/scripts/download_script.php?src_id=11834 | jar xvf -
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.