Como redirecionar a saída do wget como entrada para descompactar?

Você deve baixar seus arquivos para um arquivo temporário, porque (citando o unzip página man):

Arquivos lidos da entrada padrão ainda não são suportados, exceto com funzip (e então apenas o primeiro m a brasa do arquivo pode ser extraída).

Basta reunir os comandos:

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

Mas, para torná-lo mais flexível, você provavelmente deve colocá-lo em um script para economizar alguma digitação e para ter certeza de não sobrescrever algo acidentalmente, você pode usar o mktemp comando para criar um nome de arquivo seguro para seu arquivo temporário:

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

Comentários

• É wget file.zip && unzip file.zip o mesmo que wget file.zip; unzip file.zip ou um é preferível ao outro? Obrigado 🙂
• @NextLocal wget && unzip executará a descompactação somente se o wget for bem-sucedido. wget ; unzip executará descompactação de qualquer maneira, possivelmente apontando para um arquivo inexistente.
• funzip era a resposta que eu procurava. O Terraform (por algum motivo) empacota ‘ s binário como um único arquivo em um arquivo zip, portanto, era perfeito para mim.

Esta é uma repostagem de minha resposta a uma pergunta semelhante:

O formato de arquivo ZIP inclui um diretório (índice) no final do arquivo. Este diretório diz onde, dentro do arquivo, cada arquivo está localizado e, portanto, permite um acesso rápido e aleatório, sem ler todo o arquivo.

Isso parece representar um problema ao tentar ler um arquivo ZIP através de pipe, no sentido de que o índice não é acessado até o final e, portanto, os membros individuais não podem ser extraídos corretamente até que o arquivo tenha sido totalmente lido e não esteja mais disponível. Assim, não é surpreendente que a maioria dos descompressores ZIP simplesmente falhem quando o arquivo é fornecido por meio de um tubo.

O diretório no final do arquivo não é o único local onde o arquivo meta as informações são armazenadas no arquivo. Além disso, as entradas individuais também incluem essas informações em um cabeçalho de arquivo local, para fins de redundância.

Embora nem todo descompressor ZIP use cabeçalhos de arquivo local quando o índice não estiver disponível, os front-ends tar e cpio para libarchive (também conhecido como bsdtar e bsdcpio) podem e irão fazer isso quando ler através de um tubo, o que significa que o seguinte é possível:

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

Comentários

• Isso é excelente ! Eu observaria que o tar me dá alguns avisos sobre os dados descompactados serem do tamanho errado (esperado 0), mas os próprios arquivos parecem não estar danificados. Supondo que isso seja devido à falta do índice.
• Eu tenho um .zip -arquivo aqui que contém arquivos com permissões executáveis. Quando faço o download e canalizo para bsdtar, os bits exec são jogados fora. Quando faço download para o disco e extraio com bsdtar ou unzip, os bits exec são respeitados.
• // , @GolarRamblar, alguma vez descobriu o porquê?
• @NathanBasanese: aqui é a resposta. Resumindo: um arquivo ZIP possui dois locais onde armazena tais informações, que podem ser inconsistentes, e dependendo se o arquivo bsdtar aberto é pesquisável ou não ele usa um ou outro local .

Se você tiver o JDK instalado, pode usar jar:

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

Comentários

• Acabei de descobrir que jar não ‘ não preserva as permissões do arquivo. Caso contrário, belo truque.
• Você não ‘ não precisa fornecer um parâmetro de arquivo, basta usar | jar xv
• Eu também fui mordido pela suposição de que jar poderia ser usado como um substituto para unzip; Infelizmente, jar não restaura os arquivos extraídos ‘ permissões;
• Basta usar | jar x
• jar é muito mais agradável para lidar com nomes de arquivo UTF-8. unzip coisas mutiladas.

Eu não acho que você deseja até mesmo canalizar a saída do wget para descompactá-la.

Do artigo wikipedia “ZIP (formato de arquivo)” :

Um arquivo ZIP é identificado pela presença de um diretório central localizado no final do arquivo.

O wget tem que terminar completamente o download antes que a descompactação possa fazer qualquer trabalho, então eles são executados sequencialmente, não entrelaçados como se poderia pensar.

Repostagem de minha resposta :

BusyBox “s unzip pode pegar stdin e extrair todos os arquivos.

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

O traço após unzip é usar stdin como entrada.

Você pode até,

cat file.zip | busybox unzip - 

Mas isso é apenas redundante de unzip file.zip.

Se sua distribuição usa BusyBo x por padrão (por exemplo Alpine), basta executar unzip -.

Comentários

• mais para @Saftever ‘ s resposta, que eu ‘ m não tenho permissão para comentar, o busybox funcionará, mas versões anteriores a 1.27.0 ganharam ‘ t devido a um lseek redundante, veja o changelog busybox.net

A sintaxe apropriada seria:

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

mas não funcionará, por causa do erro ( Info-ZIP em 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. 

ou em BSD / OS X:

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

Isso ocorre porque as ferramentas zip padrão usam principalmente lseek função para definir o deslocamento do arquivo no final para ler seu final do registro do diretório central . Ele está localizado no final da estrutura do arquivo e é necessário para ler a lista dos arquivos (ver: Estrutura do formato de arquivo Zip ). Portanto, o arquivo não pode ser FIFO, canal, dispositivo de terminal ou qualquer outro dinâmico, porque o objeto de entrada não pode ser posicionado pela função lseek.

Então você tem a função seguintes soluções alternativas:

• use diferentes tipos de compactação (por exemplo, tar.gz),
• você deve usar dois comandos separados,
• use ferramentas alternativas (como sugerido em outras respostas),
• crie um alias ou função para usar vários comandos.

Comentários

• Acho que ainda poderia ser um FIFO. Você ‘ d apenas tem que continuar lendo do FIFO até o EOF (efetivamente armazenando todo o FIFO na memória ou em um arquivo temporário). Totalmente factível para facilitar a criação de scripts, mas não é muito útil.

Se houver apenas um arquivo em zip, você pode usar zcat ou gunzip:

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

Para sua informação: aqui estão as definições de gunzip e zcat em meu sistema:

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

Um arquivo zip não é sequencial porque geralmente contém o índice no final do arquivo, por isso é difícil descompactá-lo em fluxo.

Uma solução alternativa é ver se você pode obter outro formato de arquivo, como .tar.gz.

Por exemplo, se você “estiver baixando um .zip arquivo do GitHub, quase sempre há um .tar.gz versão disponível.

Por exemplo,

• 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

Observe o padrão – basta substituir .zip por .tar.gz e direcionar para | tar xzf -

Isso funciona muito bem para mim:

 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 -