Hvordan omdirigeres output af wget som input til udpakning?

Du skal downloade dine filer til en temp-fil, fordi (citerer unzip mand side):

Arkiver læst fra standard input understøttes endnu ikke, undtagen med funzip (og derefter kun den første m medlem af arkivet kan ekstraheres).

Bare kommandoerne samles:

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

Men for at gøre det mere fleksibelt, skal du sandsynligvis sætte det i et script, så du gemmer nogle indtastninger og for at sikre, at du ikke ved et uheld overskriver noget, kan du bruge mktemp kommando for at oprette et sikkert filnavn til din temp-fil:

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

Kommentarer

• Er wget file.zip && unzip file.zip det samme som wget file.zip; unzip file.zip eller foretrækkes den ene frem for den anden? Tak 🙂
• @NextLocal wget && unzip kører kun udpakning, hvis wget lykkedes. wget ; unzip vil alligevel køre udpakket og muligvis pege på ikke-eksisterende fil.
• funzip var det svar, jeg ledte efter. Terraform (af en eller anden grund) pakker den ‘ s binær som en enkelt fil i et zip-arkiv, så dette var perfekt for mig.

Dette er en repost af mit svar på et lignende spørgsmål:

ZIP-filformatet inkluderer et bibliotek (indeks) i slutningen af arkivet. Denne mappe siger, hvor inden for arkivet hver fil er placeret og muliggør således hurtig, tilfældig adgang uden at læse hele arkivet.

Dette ser ud til at udgøre et problem, når du forsøger at læse et ZIP-arkiv gennem en rør, idet der ikke er adgang til indekset indtil slutningen, og så individuelle medlemmer ikke kan udpakkes korrekt, før filen er læst helt og ikke længere er tilgængelig. Som sådan ser det ud til at være overraskende, at de fleste ZIP-dekompressorer simpelthen fejler, når arkivet leveres gennem et rør.

Kataloget i slutningen af arkivet er ikke den eneste placering, hvor filmeta oplysninger gemmes i arkivet. Derudover inkluderer individuelle poster også disse oplysninger i en lokal filoverskrift til redundansformål.

Selvom ikke alle ZIP-dekompressorer bruger lokale filoverskrifter, når indekset ikke er tilgængeligt, vil tjære- og cpio-fronten ende til libarchive (aka bsdtar og bsdcpio) kan og vil gøre det, når læsning gennem et rør, hvilket betyder, at følgende er muligt:

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

Kommentarer

• Dette er fremragende ! Jeg vil bemærke, at tjære giver mig nogle advarsler om, at de ukomprimerede data er i den forkerte størrelse (forventet 0), men filerne selv ser ud til at være ubeskadigede. Gætte på dette skyldes manglen på indekset.
• Jeg har en .zip -fil her, der indeholder filer med eksekverbare tilladelser. Når jeg downloader og piber til bsdtar, smides exec-bitene væk. Når jeg downloader til disk og udpakker med bsdtar eller unzip, bliver exec-bitene hædret.
• // , @GolarRamblar, har du nogensinde fundet ud af hvorfor?
• @NathanBasanese: her er svaret. Kort sagt: Et ZIP-arkiv har to steder, hvor det gemmer sådanne oplysninger, der kan være inkonsekvente, og afhængigt af om filen bsdtar åbnes, kan det søges, eller det bruger ikke det ene eller andet sted .

Hvis du har JDK installeret, kan du bruge jar:

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

Kommentarer

• Jeg fandt lige ud af, at jar beholder ikke ‘ t filtilladelser. Godt trick ellers.
• Du behøver ikke ‘ behøver ikke at give en filparameter, brug bare | jar xv
• Også jeg blev bidt af antagelsen, end jar kunne bruges som erstatning for unzip; Desværre jar gendanner ikke udpakkede filer ‘ tilladelser;
• Brug bare | jar x
• jar er meget pænere med at håndtere UTF-8-filnavne. unzip manglende ting.

Jeg har ikke t tror du endda vil gider at røre wgets output til udpakning.

Fra wikipedia “ZIP (filformat)” artikel:

En ZIP-fil identificeres ved tilstedeværelsen af et centralt bibliotek i slutningen af filen.

wget skal fuldføre overførslen fuldstændigt, før unzip kan udføre noget arbejde, så de kører sekventielt, ikke sammenvævet som man måske tror.

Repost af mit svar :

BusyBox “s unzip kan tage stdin og udpakke alle filerne.

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

Dash efter unzip er at bruge stdin som input.

Du kan endda,

cat file.zip | busybox unzip - 

Men det er bare overflødigt med unzip file.zip.

Hvis din distro bruger BusyBo x som standard (f.eks. Alpine), kør bare unzip -.

Kommentarer

• videre til @Saftever ‘ s svar, som jeg ‘ ikke har lov til at kommentere, busybox fungerer, men versioner ældre end 1.27.0 vandt ‘ t på grund af en overflødig undersøgelse, se changelog busybox.net

Den korrekte syntaks ville være:

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

men det fungerer ikke på grund af fejlen ( 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 

Dette skyldes, at standard zip-værktøjerne hovedsageligt bruger lseek funktion for at indstille filforskydningen i slutningen for at læse dens ende af den centrale biblioteksrekord . Den er placeret i slutningen af arkivstrukturen, og det er nødvendigt at læse listen af filerne (se: Zip-filformatstruktur ). Derfor kan filen ikke være FIFO, rør, terminalenhed eller anden dynamik, fordi inputobjektet ikke kan placeres af lseek -funktionen.

Så du har følgende løsninger:

• brug en anden form for komprimering (f.eks. tar.gz),
• du skal bruge to separate kommandoer,
• brug alternative værktøjer (som foreslået i andre svar),
• opret et alias eller funktion til at bruge flere kommandoer.

Kommentarer

• Jeg tror, det stadig kunne være en FIFO. Du ‘ er bare nødt til at fortsætte med at læse fra FIFO indtil EOF (effektivt buffere hele FIFO i hukommelsen eller i en temp-fil). Fuldstændig gennemførlig for at lette oprettelse af script, men ikke særlig nyttig.

Hvis der kun er en fil i zip, du kan bruge zcat eller gunzip:

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

FYI: Her er definitionerne af gunzip og zcat på mit system:

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

Et zip arkiv er ikke sekventielt, fordi det ofte har indholdsfortegnelsen i slutningen af filen, så det er vanskeligt at streame pakke den ud.

En alternativ løsning er at se, om du kan få et andet filformat, f.eks. .tar.gz.

Hvis du f.eks. downloader en .zip -fil fra GitHub, er der næsten altid en .tar.gz version tilgængelig.

For eksempel

• 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æg mærke til mønsteret – bare udskift .zip med .tar.gz og rør til | tar xzf -

Dette fungerer ret godt for 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 -