Hur omdirigerar du wget-utdata som input för att packa upp?

Du måste ladda ner dina filer till en temp-fil, för (citerar unzip mansida):

Arkiv som läses från standardinmatning stöds ännu inte, förutom med funzip (och då bara den första m arkivet kan extraheras).

För bara kommandona:

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

Men för att göra det mer flexibelt bör du antagligen lägga in det i ett skript så att du sparar lite skrivning och för att se till att du inte råkar skriva över något du kan använda mktemp kommando för att skapa ett säkert filnamn för din temporära fil:

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

Kommentarer

• Är wget file.zip && unzip file.zip samma som wget file.zip; unzip file.zip eller föredras en över den andra? Tack 🙂
• @NextLocal wget && unzip körs unzip bara om wget lyckades. wget ; unzip kommer att köras unzip ändå, eventuellt pekande på obefintlig fil.
• funzip var svaret jag letade efter. Terraform (av någon anledning) paketerar den ’ s binär som en enda fil i ett zip-arkiv så det här var perfekt för mig.

Detta är en repost av mitt svar på en liknande fråga:

ZIP-filformatet innehåller en katalog (index) i slutet av arkivet. Den här katalogen säger var i arkivet varje fil finns och därmed möjliggör snabb, slumpmässig åtkomst utan att läsa hela arkivet.

Detta verkar utgöra ett problem när du försöker läsa ett ZIP-arkiv genom en rör, genom att indexet inte nås förrän i slutet och så att enskilda medlemmar inte kan extraheras korrekt förrän efter att filen har lästs helt och inte längre är tillgänglig. Som sådan verkar det inte förvånande att de flesta ZIP-dekompressorer helt enkelt misslyckas när arkivet levereras genom ett rör.

Katalogen i slutet av arkivet är inte den enda platsen där filmeta information lagras i arkivet. Dessutom innehåller enskilda poster även denna information i ett lokalt filrubrik för redundansändamål.

Även om inte alla ZIP-dekompressorer använder lokala filrubriker när indexet inte är tillgängligt, tar tar- och cpio-fronten till libarchive (aka bsdtar och bsdcpio) kan och kommer att göra när läser igenom ett rör, vilket betyder att följande är möjligt:

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

Kommentarer

• Detta är utmärkt ! Jag skulle notera att tjära ger mig några varningar om att de okomprimerade uppgifterna har fel storlek (förväntat 0), men själva filerna verkar vara oskadade. Att gissa detta beror på bristen på index.
• Jag har en .zip -fil här som innehåller filer med körbara behörigheter. När jag laddar ner och rör till bsdtar kastas exec-bitarna. När jag laddar ner till disk och extraherar med bsdtar eller unzip då är exec-bitarna hedrade.
• // , @GolarRamblar, fick du någonsin veta varför?
• @NathanBasanese: här är svaret. Kort sagt: Ett ZIP-arkiv har två platser där den lagrar sådan information, som kan vara inkonsekvent, och beroende på om filen bsdtar öppnas är sökbar eller använder den inte den ena eller den andra platsen .

Om du har JDK installerad kan du använda jar:

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

Kommentarer

• Jag fann just att jar behåller inte ’ t behåller filbehörigheter. Trevligt trick annars.
• Du behöver inte ’ behöver inte ge en filparameter, använd bara | jar xv
• Jag blev också biten av antagandet att jar kunde användas som ersättning för unzip; Tyvärr återställer jar inte extraherade filer ’ behörigheter;
• Använd bara | jar x
• jar är mycket trevligare att hantera UTF-8-filnamn. unzip lurade saker.

Jag vet inte tror att du ens vill bry dig om att pipa wget ”s ut i packa upp.

Från wikipedia ” ZIP (filformat) ” artikel:

En ZIP-fil identifieras genom närvaron av en central katalog i slutet av filen.

wget måste slutföra nedladdningen helt innan unzip kan göra något arbete, så de körs i följd, inte sammanvävda som man kan tro.

Repost of mitt svar :

BusyBox ”s unzip kan ta stdin och extrahera alla filer.

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

Strecket efter unzip är att använda stdin som inmatning.

Du kan även,

cat file.zip | busybox unzip - 

Men det är bara överflödigt av unzip file.zip.

Om din distro använder BusyBo x som standard (t.ex. Alpine), kör bara unzip -.

Kommentarer

• vidare till @Saftever ’ s svar som jag ’ inte får kommentera, upptagenbox fungerar men versioner äldre än 1.27.0 vann ’ t på grund av en redundant sökning, se ändringslogg busybox.net

Den korrekta syntaxen skulle vara:

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

men det fungerar inte på grund av felet ( Info-ZIP på 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. 

eller på BSD / OS X:

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

Detta beror på att standard zip-verktygen huvudsakligen använder lseek funktion för att ställa in filförskjutningen i slutet för att läsa dess slutet av den centrala katalogposten . Den ligger i slutet av arkivstrukturen och du måste läsa listan av filerna (se: Zip-filformatsstruktur ). Därför kan filen inte vara FIFO, rör, terminalenhet eller någon annan dynamik, eftersom ingångsobjektet inte kan placeras av lseek -funktionen.

Så du har följande lösningar:

• använder annan typ av kompression (t.ex. tar.gz),
• du måste använda två separata kommandon,
• använd alternativa verktyg (som föreslås i andra svar),
• skapa ett alias eller funktion för att använda flera kommandon.

Kommentarer

• Jag tror att det fortfarande kan vara en FIFO. Du ’ behöver bara fortsätta läsa från FIFO tills EOF (effektivt buffrar hela FIFO i minnet eller i en temp-fil). Helt genomförbart för att underlätta skapandet av skript, men inte särskilt användbart.

Om det bara finns en fil i zip, du kan använda zcat eller gunzip:

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

FYI: Här är definitionerna av gunzip och zcat på mitt system:

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

Ett zip arkiv är inte sekventiellt eftersom det ofta har innehållsförteckningen i slutet av filen, så det är svårt att strömma upp den.

En alternativ lösning är att se om du kan få ett annat filformat, som .tar.gz.

Om du till exempel laddar ner en .zip -fil från GitHub finns det nästan alltid en .tar.gz version tillgänglig.

Till exempel

• 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

Lägg märke till mönstret – ersätt bara .zip med .tar.gz och rör till | tar xzf -

Det fungerar ganska bra för mig:

 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 -