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

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.

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

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-

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

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

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.

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.

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 -.

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 -