Wie leite ich die Ausgabe von wget als Eingabe zum Entpacken um?

Ich muss eine Datei von diesem Link herunterladen . Der Dateidownload ist eine Zip-Datei, die ich im aktuellen Ordner entpacken muss.

Normalerweise würde ich es zuerst herunterladen und dann den Befehl zum Entpacken ausführen.

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

Aber auf diese Weise muss ich zwei Befehle ausführen, auf den Abschluss des ersten warten, um den nächsten auszuführen. Außerdem muss ich den Namen der Datei kennen temp.zip, der es geben soll unzip.

Ist es möglich, die Ausgabe von wgetnach umzuleiten unzip? So etwas wie

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

Aber es hat nicht funktioniert.

Bash:: wget http://www.vim.org/scripts/download_script.php?src_id=11834 -O temp.zipMehrdeutige Weiterleitung

Auch wgetwurde ausgeführt zweimal, und die Datei heruntergeladen zweimal.

Sie müssen Ihre Dateien in eine temporäre Datei herunterladen, da (unter Angabe der Manpage zum Entpacken):

Von der Standardeingabe gelesene Archive werden noch nicht unterstützt, außer mit funzip (und dann kann nur das erste Mitglied des Archivs extrahiert werden).

Bringen Sie einfach die Befehle zusammen:

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

Aber um es flexibler zu machen, sollten Sie es wahrscheinlich in ein Skript einfügen, damit Sie etwas Tipparbeit sparen und um sicherzustellen, dass Sie nicht versehentlich etwas überschreiben, können Sie den mktempBefehl verwenden, um einen sicheren Dateinamen für Ihre temporäre Datei zu erstellen:

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

Dies ist eine Wiederholung meiner Antwort auf eine ähnliche Frage:

Das ZIP-Dateiformat enthält ein Verzeichnis (Index) am Ende des Archivs. In diesem Verzeichnis steht, wo sich innerhalb des Archivs jede Datei befindet und ermöglicht so einen schnellen, zufälligen Zugriff, ohne das gesamte Archiv zu lesen.

Dies scheint ein Problem zu sein, wenn versucht wird, ein ZIP-Archiv über eine Pipe zu lesen, da erst ganz am Ende auf den Index zugegriffen wird und daher einzelne Mitglieder erst dann korrekt extrahiert werden können, wenn die Datei vollständig gelesen wurde und nicht mehr verfügbar ist . Als solches erscheint es nicht überraschend, dass die meisten ZIP-Dekomprimierer einfach versagen, wenn das Archiv über eine Pipe geliefert wird.

Das Verzeichnis am Ende des Archivs ist nicht der einzige Ort, an dem Datei-Metainformationen im Archiv gespeichert werden. Darüber hinaus enthalten einzelne Einträge diese Informationen aus Redundanzgründen auch in einem lokalen Dateikopf.

Obwohl nicht jeder ZIP-Dekomprimierer lokale Dateiheader verwendet, wenn der Index nicht verfügbar ist, können und werden die Frontends tar und cpio für libarchive (auch bekannt als bsdtar und bsdcpio) beim Durchlesen einer Pipe verwendet. Dies bedeutet, dass Folgendes möglich ist:

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

Wenn Sie das JDK installiert haben, können Sie Folgendes verwenden jar:

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

Ich glaube nicht, dass Sie sich die Mühe machen wollen, die Ausgabe von wget in unzip zu leiten.

Aus dem Wikipedia- Artikel "ZIP (Dateiformat)" :

Eine ZIP-Datei wird durch das Vorhandensein eines zentralen Verzeichnisses am Ende der Datei identifiziert.

wget muss den Download vollständig abschließen, bevor unzip irgendwelche Arbeiten ausführen kann. Daher werden sie nacheinander ausgeführt und nicht miteinander verwoben, wie man denkt.

Die richtige Syntax wäre:

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

aber es wird nicht funktionieren, wegen des Fehlers ( Info-ZIP unter 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.

oder unter BSD / OS X:

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

Dies liegt daran, dass die Standard-Zip-Tools hauptsächlich lseekFunktionen verwenden, um den Datei-Offset am Ende so einzustellen, dass das Ende des zentralen Verzeichnisdatensatzes gelesen wird . Sie befindet sich am Ende der Archivstruktur und muss die Liste der Dateien lesen (siehe: Zip-Dateiformatstruktur ). Daher kann die Datei kein FIFO, keine Pipe, kein Endgerät oder eine andere Dynamik sein, da das Eingabeobjekt von der lseekFunktion nicht positioniert werden kann.

Sie haben also die folgenden Problemumgehungen:

• andere Art der Komprimierung verwenden (zB tar.gz),
• Sie müssen zwei separate Befehle verwenden,
• Verwenden Sie alternative Tools (wie in anderen Antworten vorgeschlagen).
• Erstellen Sie einen Alias ​​oder eine Funktion, um mehrere Befehle zu verwenden.

Repost meiner Antwort :

BusyBox's unzipkönnen stdin nehmen und alle Dateien extrahieren.

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

Der Bindestrich danach unzipist stdin als Eingabe zu verwenden.

Du kannst sogar,

cat file.zip | busybox unzip -

Aber das ist einfach überflüssig unzip file.zip.

Wenn Ihre Distribution standardmäßig BusyBox verwendet (z. B. Alpine), starten Sie einfach unzip -.

Das funktioniert bei mir ganz gut:

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 -