Hogyan lehet átirányítani a wget kimenetét bemenetként a kibontáshoz?

A fájlokat le kell töltenie egy temp fájlba, mert (a kicsomagolást idézve man oldal):

A standard bemenetről olvasott archívumok még nem támogatottak, kivéve a funzip-et (és akkor csak az első m az archívum embere kinyerhető).

Csak hozza össze a parancsokat:

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

De a rugalmasság érdekében valószínűleg be kell illesztenie egy szkriptbe, így elment egy kis gépelést, és annak biztosítása érdekében, hogy véletlenül ne írjon felül valamit, használhatja a mktemp parancs biztonságos fájlnév létrehozásához a temp fájlhoz:

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

Megjegyzések

• wget file.zip && unzip file.zip ugyanaz, mint a wget file.zip; unzip file.zip, vagy előnyben részesítik az egyiket a másikkal szemben? Köszönöm 🙂
• @NextLocal wget && unzip csak akkor futtatja a kicsomagolást, ha a wget sikeres volt. A wget ; unzip úgyis kibontja a csomagolást, esetleg a nem létező fájlra mutat.
• A funzip volt a válasz, amit kerestem. A Terraform (valamilyen oknál fogva) ‘ bináris fájlokat egyetlen fájlként csomagol egy zip archívumba, így ez tökéletes volt számomra.

Ez a válaszom újbóli elküldése hasonló kérdésre:

A ZIP fájlformátum könyvtárat (indexet) tartalmaz az archívum végén. Ez a könyvtár megadja, hogy az archívumon belül hol találhatók az egyes fájlok, és ezáltal gyors, véletlenszerű hozzáférést tesz lehetővé a teljes archívum elolvasása nélkül.

Úgy tűnik, hogy ez problémát jelent, amikor megpróbálja elolvasni a ZIP-archívumot pipe, mivel az index csak a végéig érhető el, így az egyes tagokat csak akkor lehet helyesen kibontani, ha a fájl teljesen el lett olvasva, és már nem állnak rendelkezésre. Mint ilyen, nem meglepő, hogy a legtöbb ZIP dekompresszor egyszerűen meghibásodik, ha az archívumot csövön keresztül szállítják.

Az archívum végén található könyvtár nem az a egyetlen hely, ahol a fájl meta az információkat az archívum tárolja. Ezenkívül az egyedi bejegyzések redundancia céljából ezeket az információkat tartalmazzák egy helyi fájl fejlécében is.

Bár nem minden ZIP dekompresszor használ helyi fájlfejléceket, amikor az index nem érhető el, a tar és a cpio kezelőfelületei libarchiválódnak (más néven bsdtar és bsdcpio) pipán keresztül olvasva, ami azt jelenti, hogy a következő lehetséges:

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

Megjegyzések

• Ez kiváló ! Megjegyezném, hogy a tar némi figyelmeztetést ad arra, hogy a tömörítetlen adatok nem megfelelő méretűek (várhatóan 0), de úgy tűnik, hogy maguk a fájlok is sértetlenek. Ezt sejteni az index hiánya okozza.
• Van itt egy .zip fájlom, amely futtatható engedélyekkel rendelkező fájlokat tartalmaz. Amikor letöltök és átmegyek a bsdtar fájlba, az exec bitek eldobódnak. Amikor letöltöm lemezre, és kibontom a következőt: bsdtar vagy unzip, akkor az exec biteket tiszteletben tartjuk.
• // , @GolarRamblar, valaha is megtudta, miért?
• @NathanBasanese: itt a válasz. Röviden: A ZIP-archívumnak két helye van, ahol ilyen információkat tárol, amelyek inkonzisztensek lehetnek, és attól függően, hogy a bsdtar fájl megnyílik-e, vagy sem az egyik, vagy a másik helyet használja .

Ha telepítve van a JDK, használhatja a jar:

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

megjegyzések

• most tapasztaltam, hogy jar nem ‘ nem őrzi meg a fájlengedélyeket. Szép trükk egyébként.
• Nem kell ‘ fájlparamétert megadni, csak használja a | jar xv
• Engem is megharapott a feltételezés, mivel a jar felhasználható a unzip helyettesítésére; Sajnos a jar nem állítja vissza a kibontott fájlok ‘ engedélyeket;
• csak a | jar x
• jar sokkal szebb az UTF-8 fájlnevek kezelése. unzip összekeverte a dolgokat.

Nem tudom úgy gondolja, hogy még a wget kimenetének kibontását is szeretné kibontani.

A wikipedia “ZIP (fájlformátum)” cikkből:

A ZIP-fájlt a fájl végén található központi könyvtár jelenléte azonosítja.

A wget-nek teljesen le kell töltenie a letöltést, mielőtt a kibontás bármilyen munkát elvégezhetne, ezért egymás után futnak, nem fonódnak össze, mint gondolnánk. div class = “answer”>

A válaszom újrabeillesztése:

BusyBox “s unzip be tudja venni az stdin-t, és kibontani az összes fájlt.

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

A unzip után a kötőjel az bemenetként.

Akár,

cat file.zip | busybox unzip - 

De ez csak felesleges a unzip file.zip.

Ha a disztribútor a BusyBo-t használja x alapértelmezés szerint (pl. Alpine), csak futtassa unzip -.

Megjegyzések

• tovább a @Saftever válasz, amelyet én ‘ nem kommentálhatok, a busybox működni fog, de az 1.27.0-nél régebbi verziók nyertek ‘ t egy redundáns lekérdezés miatt, lásd a changelog busybox.net

A megfelelő szintaxis a következő lenne:

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

de a hiba miatt nem fog működni ( Info-ZIP a Debian -en):

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. 

vagy BSD / OS X rendszeren:

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

Ez azért van, mert a szokásos ZIP-eszközök főleg a lseek function annak érdekében, hogy a fájl eltolását beállítsuk a központi könyvtárrekord végének beolvasására. Az archív struktúra végén található, és el kell olvasnia a listát fájlok (lásd: Zip fájlformátum-szerkezet ). Ezért a fájl nem lehet FIFO, cső, végberendezés vagy bármilyen más dinamikus, mert a bemeneti objektumot nem tudja elhelyezni a lseek függvény.

Tehát megvan a a következő megoldások:

• használjon másfajta tömörítést (pl. tar.gz),
• két külön parancsot kell használnia,
• használjon alternatív eszközöket (ahogy azt a többi válasz is javasolja),
• hozzon létre álnevet vagy függvényt több parancs használatához.

Megjegyzések

• Azt hiszem, ez még mindig lehet FIFO. ‘ csak folytatnia kell az olvasást a FIFO-tól az EOF-ig (a teljes FIFO pufferelése gyakorlatilag a memóriában vagy egy temp fájlban). Teljesen kivitelezhető a szkriptkészítés megkönnyítése érdekében, de nem túl hasznos.

Ha csak egy fájl van a zip, használhatja a zcat vagy a gunzip:

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

FYI: Itt vannak az gunzip és zcat definíciók a rendszeremen:

$ grep ^exec $(which gunzip zcat) /bin/gunzip:exec gzip -d "$@" /bin/zcat:exec gzip -cd "$@" 

A zip archívum nem egymást követő, mert gyakran van benne tartalomjegyzék a fájl végén, így nehéz a kicsomagolást kicsomagolni.

Alternatív megoldás az, ha megtudja, hogy kaphat-e másik fájlformátumot, például .tar.gz.

Ha például egy .zip fájlt tölt le a GitHub-ból, akkor szinte mindig van egy .tar.gz verzió elérhető.

Például:

• https://github.com/madler/zlib/archive/v1.2.11.zip
• https://github.com/madler/zlib/archive/v1.2.11.tar.gz
• https://github.com/curl/curl/archive/curl-7_68_0.zip
• https://github.com/curl/curl/archive/curl-7_68_0.tar.gz

Figyelje meg a mintát – csak cserélje le az .zip szöveget .tar.gz -re, és csatolja div id = “04b882bc00”>

Ez elég jól működik nekem:

 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 -