Cum să redirecționați ieșirea wget ca intrare pentru a dezarhiva?

Trebuie să descărcați fișierele într-un fișier temporar, deoarece (citând dezarhivarea pagina man):

Arhivele citite din intrarea standard nu sunt încă acceptate, cu excepția funcționalității (și apoi numai a primului m membrul arhivei poate fi extras).

Doar aduceți comenzile împreună:

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

Dar, pentru a-l face mai flexibil, ar trebui să-l puneți într-un script, astfel încât să economisiți ceva de tastat și pentru a vă asigura că nu suprascrieți accidental ceva, puteți utiliza mktemp comandă pentru a crea un nume de fișier sigur pentru fișierul dvs. temporar:

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

Comentarii

• Este wget file.zip && unzip file.zip la fel ca wget file.zip; unzip file.zip sau este unul preferat față de celălalt? Mulțumesc 🙂
• @NextLocal wget && unzip va rula dezarhivați numai dacă wget a reușit. wget ; unzip va rula oricum dezarhivați, arătând eventual către fișierul inexistent.
• funcip a fost răspunsul pe care îl căutam. Terraform (dintr-un anumit motiv) îl împachetează ‘ binar ca un singur fișier într-o arhivă zip, deci acest lucru a fost perfect pentru mine.

Aceasta este o repostare a răspunsul meu la o întrebare similară:

Formatul fișierului ZIP include un director (index) la sfârșitul arhivei. Acest director spune unde, în cadrul arhivei, este localizat fiecare fișier și, astfel, permite accesul rapid, aleatoriu, fără a citi întreaga arhivă.

Acest lucru pare să pună o problemă la încercarea de a citi o arhivă ZIP printr-un pipe, prin faptul că indexul nu este accesat până la capăt și astfel membrii individuali nu pot fi extrși corect decât după ce fișierul a fost citit în totalitate și nu mai este disponibil. Ca atare, nu este surprinzător faptul că majoritatea decompresoarelor ZIP eșuează pur și simplu atunci când arhiva este furnizată printr-o conductă.

Directorul de la sfârșitul arhivei nu este numai locația în care fișierul meta informațiile sunt stocate în arhivă. În plus, intrările individuale includ, de asemenea, aceste informații într-un antet de fișier local, în scopul redundanței.

Deși nu fiecare decompresor ZIP va folosi anteturi de fișiere locale atunci când indexul nu este disponibil, frontul tar și cpio se termină în libarchive (aka bsdtar și bsdcpio) pot și o vor face atunci când citirea printr-o conductă, ceea ce înseamnă că este posibil următoarele:

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

Comentarii

• Acest lucru este excelent ! Aș observa că tar îmi dă câteva avertismente cu privire la faptul că datele necomprimate au dimensiunea greșită (așteptat 0), dar fișierele în sine par a fi nedeteriorate. Ghicind acest lucru se datorează lipsei indexului.
• Am un fișier .zip aici care conține fișiere cu permisiuni executabile. Când descarc și introduc în bsdtar, biții exec sunt aruncați. Când descarc pe disc și extrag cu bsdtar sau unzip atunci, biții exec sunt onorați.
• // , @GolarRamblar, nu ați aflat vreodată de ce?
• @NathanBasanese: aici este răspunsul. Pe scurt: o arhivă ZIP are două locuri în care stochează astfel de informații, care pot fi inconsistente și, în funcție de deschiderea fișierului bsdtar, este căutabil sau nu, folosește unul sau celălalt loc .

Dacă aveți JDK instalat, puteți utiliza jar:

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

Comentarii

• Tocmai am constatat că jar nu ‘ nu păstrează permisiunile fișierului. Truc frumos altfel.
• Nu ‘ nu trebuie să dați un parametru de fișier, folosiți doar | jar xv
• Și eu am fost mușcat de presupunerea că jar ar putea fi folosit ca înlocuitor pentru unzip; Din păcate, jar nu restabilește fișierele extrase ‘ permisiuni;
• Folosiți doar | jar x
• jar gestionează mult mai frumos numele de fișiere UTF-8. unzip lucruri maltratate.

Eu nu „t credeți că doriți chiar să deranjați ieșirea wget-ului în dezarhivare.

Din articolul Wikipedia „ZIP (format fișier)” :

Un fișier ZIP este identificat prin prezența unui director central situat la sfârșitul fișierului.

wget trebuie să finalizeze complet descărcarea înainte ca dezarhivarea să poată face orice lucru, astfel încât acestea să ruleze secvențial, nu întrețesute așa cum s-ar putea crede.

Repostarea răspunsul meu :

BusyBox „s unzip poate lua stdin și extrage toate fișierele.

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

Linia după unzip este de a utiliza stdin ca intrare.

Puteți chiar,

cat file.zip | busybox unzip - 

Dar asta este doar redundant al unzip file.zip.

Dacă distribuția dvs. folosește BusyBo x în mod implicit (de ex. Alpine), rulați doar unzip -.

Comentarii

• mai departe către @Saftever , pe care eu ‘ nu pot să comentez, busybox va funcționa, dar versiunile mai vechi de 1.27.0 au câștigat ‘ t datorită unei căutări redundante, consultați changelog busybox.net

Sintaxa corectă ar fi:

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

dar nu a funcționat, din cauza erorii ( Info-ZIP pe 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. 

sau pe BSD / OS X:

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

Acest lucru se datorează faptului că instrumentele zip standard utilizează în principal lseek funcție pentru a seta fișierul decalat la sfârșit pentru a citi sfârșitul înregistrării din directorul central . Acesta se află la sfârșitul structurii arhivei și este necesar să citiți lista din fișiere (vezi: Structura formatului fișierului Zip ). Prin urmare, fișierul nu poate fi FIFO, țeavă, dispozitiv terminal sau orice altă dinamică, deoarece obiectul de intrare nu poate fi poziționat prin funcția lseek.

Deci aveți următoarele soluții:

• utilizați diferite tipuri de compresie (de ex. tar.gz),
• trebuie să utilizați două comenzi separate,
• utilizați instrumente alternative (așa cum este sugerat în alte răspunsuri),
• creați un alias sau o funcție pentru a utiliza mai multe comenzi.

Comentarii

• Cred că încă ar putea fi un FIFO. ‘ trebuie doar să continuați să citiți din FIFO până la EOF (tamponând efectiv întregul FIFO în memorie sau într-un fișier temp). Total realizabil pentru a ușura crearea scriptului, dar nu foarte util.

Dacă există un singur fișier în zip, puteți utiliza zcat sau gunzip:

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

FYI: Iată definițiile gunzip și zcat din sistemul meu:

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

O arhivă zip nu este secvențială deoarece are adesea cuprinsul la sfârșitul fișierului, deci este dificil să îl dezarhivați în flux.

O soluție alternativă este să vedeți dacă puteți obține un alt format de fișier, cum ar fi .tar.gz.

De exemplu, dacă „descărcați un fișier .zip din GitHub, există aproape întotdeauna un .tar.gz versiune disponibilă.

De exemplu,

• 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

Observați modelul – pur și simplu înlocuiți .zip cu .tar.gz și țineți la | tar xzf -

Acest lucru funcționează destul de bine pentru mine:

 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 -