Observe que a compilação com suporte a depuração é sempre segura; O wget compilado com o suporte a depuração não imprimirá nenhuma informação de depuração, a menos que solicitado com -d .

Se essa função for usada, nenhum URL precisará estar presente na linha de comando. Se houver URLs na linha de comando e no arquivo de entrada, aqueles nas linhas de comando serão os primeiros a serem recuperados. Se –force-html não for especificado, o arquivo deverá consistir em uma série de URLs, um por linha.

No entanto, se você especificar –force-html, o documento será considerado como HTML. Nesse caso, você pode ter problemas com links relativos, que podem ser resolvidos adicionando <base href = ” url “> aos documentos ou especificando –base = url na linha de comando.

Se o arquivo for externo, o documento será tratado automaticamente como HTML se o Tipo de Conteúdo for ” text / html “. Além disso, a localização do arquivo será implicitamente usada como href base se nenhum foi especificado.

Por exemplo, se você especificar http: //foo/bar/a.html para URL e o wget ler ../baz/b.html no arquivo de entrada, ele será resolvido para http: // foo / baz / b .html .

Se ” – ” for usado como arquivo , os documentos serão impressos na saída padrão, desativando a conversão de links. (Use ” ./- ” para imprimir em um arquivo chamado literalmente ” – “.) O

uso de -O não significa “use o arquivo de nome em vez do arquivo na URL;” ao contrário, é análogo ao redirecionamento do shell : wget -O arquivo http: // foo deve funcionar como wget -O – http: // foo> file ; arquivo será truncadoimediatamente, e todo o conteúdo baixado será gravado lá.

Por esse motivo, -N (para verificação do carimbo de data / hora) não é suportado em combinação com -O : como o arquivo é sempre criado recentemente, ele sempre terá um carimbo de data / hora muito novo. Um aviso será emitido se essa combinação for usada.

Da mesma forma, usar -r ou -p com -O pode não funcionar como o esperado: o wget não apenas baixa o primeiro arquivo para o arquivo e depois o restante para o nome normal: todo o conteúdo baixado será colocado no arquivo. Isso foi desabilitado na versão 1.11, mas foi restabelecido (com um aviso) na 1.11.2, pois há alguns casos em que esse comportamento pode realmente ter algum uso.

Observe que uma combinação com -k é permitida apenas ao fazer o download de um único documento, pois nesse caso ele converterá todos os URIs relativos em externos; -k não faz sentido para vários URIs quando todos estão sendo baixados para um único arquivo; -k pode ser usado apenas quando a saída for um arquivo regular.

Ao executar o wget sem -N , -nc ou -r , o download do mesmo arquivo no mesmo diretório resultará na preservação da cópia original do arquivo e na segunda cópia com o nome file.1 . Se esse arquivo for baixado novamente, a terceira cópia será nomeada file.2 , e assim por diante. Quando -ncé especificado, esse comportamento é suprimido e o wget se recusará a baixar cópias mais recentes do arquivo. Portanto, “no-clobber” é um nome impróprio nesse modo: não é evitado o impedimento (como os sufixos numéricos já estavam impedindo o impedimento), mas sim o salvamento de várias versões que está sendo desativado.

Ao executar o wget com -r , mas sem -N ou -nc , o download de um arquivo resultará na nova cópia substituindo a antiga. A adição de -nc impedirá esse comportamento, fazendo com que a versão original seja preservada e as cópias mais recentes no servidor sejam ignoradas.

Ao executar o wget com -N, com ou sem -r , a decisão de baixar ou não uma cópia mais recente de um arquivo depende do carimbo de data e hora local e remoto e do tamanho do arquivo. -nc não pode ser especificado ao mesmo tempo que -N .

Observe que quando -nc for especificado, os arquivos com os sufixos .html ou .htm serão carregados do disco local e analisados ​​como se tivessem sido recuperados da Web.

wget -c ftp://sunsite.doc.ic.ac.uk/ls-lR.Z

Se houver um arquivo chamado ls-lR.Z no diretório atual, o wget assumirá que é a primeira parte do arquivo remoto e solicitará ao servidor que continue a recuperação de um deslocamento igual ao tamanho do arquivo local .

Observe que você não precisa especificar esta opção se desejar apenas que a chamada atual do wget tente novamente o download de um arquivo, caso a conexão seja perdida no meio do caminho, que é o comportamento padrão. -c afeta apenas a retomada de downloads iniciados antes dessa chamada do wget e cujos arquivos locais ainda estão parados.

Sem -c , o exemplo anterior apenas faria o download do arquivo remoto para ls-lR.Z.1, deixando o arquivo ls-lR.Z truncado sozinho.

A partir do wget 1.7, se você usar -c em um arquivo não vazio, e o servidor não suportar o download contínuo, o wget se recusará a iniciar o download do zero, o que arruinaria efetivamente o conteúdo existente. Se você realmente deseja que o download comece do zero, remova o arquivo.

Além disso, começando com o wget 1.7, se você usar -c em um arquivo de tamanho igual ao do servidor, wgetrecusará o download do arquivo e imprimirá uma mensagem explicativa. O mesmo acontece quando o arquivo é menor no servidor do que localmente (presumivelmente porque foi alterado no servidor desde a última tentativa de download), porque “continuar” não é significativo, não ocorre nenhum download.

Por outro lado, ao usar -c , qualquer arquivo que seja maior no servidor do que localmente será considerado um download incompleto e apenas os bytes (comprimento (remoto) – comprimento (local)) serão baixados e pregados no final do local Arquivo. Esse comportamento pode ser desejável em certos casos: por exemplo, você pode usar o wget -c para baixar apenas a nova parte que foi anexada a uma coleta de dados ou arquivo de log.

No entanto, se o arquivo for maior no servidor porque foi alterado, em vez de apenas anexado, você terá um arquivo ilegível. O wget não tem como verificar se o arquivo local é realmente um prefixo válido do arquivo remoto. Você precisa ser especialmente cuidadoso ao usar -c em conjunto com -r , pois cada arquivo será considerado um candidato para “download incompleto”.

Outra instância em que você obterá um arquivo ilegível se tentar usar -c é se você tiver um proxy HTTP fraco que insere uma string “transferência interrompida” no arquivo local. No futuro, uma opção de “reversão” poderá ser adicionada para lidar com este caso.

Observe que -c só funciona com servidores FTP e com servidores HTTP compatíveis com o cabeçalho “Range”.

O indicador ” bar ” é usado por padrão. Ele desenha uma barra de progresso ASCII (também conhecida como “termômetro”), indicando o status da recuperação. Se a saída não for um TTY, a barra ” ponto ” será usada por padrão.

Use –progress = dot para alternar para a exibição ” ponto “. Ele rastreia a recuperação imprimindo pontos na tela, cada ponto representando uma quantidade fixa de dados baixados.

Ao usar a recuperação pontilhada, você também pode definir o estilo especificando o tipo como dot: style. Estilos diferentes atribuem significado diferente a um ponto. Com o estilo ” padrão “, cada ponto representa 1 K , há dez pontos em um cluster e 50 pontos em uma linha. O estilo ” binário ” possui uma orientação mais semelhante ao “computador”: 8 K pontos, aglomerados de 16 pontos e 48 pontos por linha (o que resulta em 384 K linhas). O estilo ” mega ” é adequado para baixar arquivos muito grandes; cada ponto representa 6 4K recuperados, há oito pontos em um cluster e 48 pontos em cada linha (portanto, cada linha contém 3 M).

Observe que você pode definir o estilo padrão usando o comando progress em .wgetrc . Essa configuração pode ser substituída na linha de comando. A exceção é que,o ponto “progresso será favorecido sobre” bar “. Para forçar a saída da barra, use –progress = bar: force .

Por padrão, quando um arquivo é baixado, seus registros de data e hora são definidos para corresponder aos do arquivo remoto, o que permite o uso de –timestamping nas chamadas subseqüentes do wget . No entanto, às vezes é útil basear o registro de data e hora do arquivo local quando ele foi realmente baixado; para esse fim, a opção –no-use-server-timestamps foi fornecida.

wget --spider --force-html -i bookmarks.html

Esse recurso precisa de muito mais trabalho para o wget se aproximar da funcionalidade de aranhas da web reais.

Ao interagir com a rede, o wget pode verificar o tempo limite e abortar a operação se demorar muito. Isso evita anomalias como leituras suspensas e conexões infinitas. O único tempo limite ativado por padrão é um tempo limite de leitura de 900 segundos. Definir um tempo limite como 0 desativa-o completamente. A menos que você saiba o que está fazendo, é melhor não alterar as configurações de tempo limite padrão.

Todas as opções relacionadas ao tempo limite aceitam valores decimais e valores de subsegundos. Por exemplo,0,1 segundos é uma opção legal (embora não sensata) de tempo limite. Os tempos limite de subsegundos são úteis para verificar os tempos de resposta do servidor ou testar a latência da rede .

Esta opção permite o uso de números decimais, geralmente em conjunto com sufixos de potência; por exemplo, –limit-rate = 2.5k é um valor legal.

Note que o wgetimplementa a limitação adormecendo a quantidade de tempo apropriada após uma leitura da rede que levou menos tempo do que o especificado pela taxa. Eventualmente, essa estratégia faz com que a transferência TCP diminua para aproximadamente a taxa especificada. No entanto, pode levar algum tempo para que esse equilíbrio seja alcançado; portanto, não se surpreenda se a limitação da taxa não funcionar bem com arquivos muito pequenos.

Especificar um valor grande para esta opção é útil se a rede ou o host de destino estiver inativo, para que o wget possa esperar o tempo suficiente para esperar razoavelmente que o erro de rede seja corrigido antes da nova tentativa. O intervalo de espera especificado por esta função é influenciado por –random-wait (veja abaixo).

Por padrão, o wget assumirá um valor de 10 segundos.

Observe que a cota nunca afetará o download de um único arquivo. Portanto, se você especificar wget -Q10k ftp://wuarchive.wustl.edu/ls-lR.gz , todos os ls-lR.gz serão baixados. O mesmo acontece mesmo quando várias URLs são especificadas na linha de comando. No entanto, a cota é respeitada ao recuperar recursivamente ou de um arquivo de entrada. Assim, você pode digitar com segurança os sites wget -Q2m -i ; o download será interrompido quando a cota for excedida.

Definindo cota para 0 ou parainf limita a cota de download.

No entanto, foi relatado que em algumas situações não é desejável armazenar em cache nomes de host, mesmo durante a duração de um aplicativo de execução curta como o wget . Com esta opção, o wget emite uma nova pesquisa de DNS (mais precisamente, uma nova chamada para ” gethostbyname ” ou ” getaddrinfo“) sempre que estabelecer uma nova conexão. Observe que esta opção não afetará o cache que pode ser executado pela biblioteca de resolução ou por uma camada de cache externa, como o NSCD.

Por padrão, o wget escapa os caracteres que não são válidos como parte dos nomes de arquivo no sistema operacional, além de controlar os caracteres que normalmente não são imprimíveis. Essa opção é útil para alterar esses padrões, porque você está baixando para uma partição não nativa ou porque deseja desativar o escape dos caracteres de controle.

Os modossão um conjunto de valores de texto separados por vírgula. Os valores aceitáveis ​​são unix , windows , nocontrol , ascii , minúsculo e maiúsculo . Os valores unix e windows são mutuamente exclusivos (um substituirá o outro), assim como minúsculas e maiúsculas . Esses últimos são casos especiais, pois não alteram o conjunto de caracteres que seriam escapados, mas forçam os caminhos de arquivos locais a serem convertidos em minúsculas ou maiúsculas.

Quando o modo está definido como unix , o wget escapa do caractere /e os caracteres de controlo nas gamas de 0 – 31 e 128 – 159 . Esta opção é o padrão em sistemas operacionais semelhantes ao Unix .

Quando o modo está definido como windows , o wget escapa dos caracteres \ , | , / , : , ? , “ , * , < , > e os caracteres de controle nos intervalos 0 – 31 e 128 – 159. Além disso, o wgetno modo Windows, usa + em vez de : para separar host e porta em nomes de arquivos locais e usa @ em vez de & para separar a parte da consulta do nome do arquivo do resto. Portanto, um URL que seria salvo como www.xemacs.org:4300/search.pl?input=blah no modo Unix seria salvo como www.xemacs.org + 4300 / search.pl@input = blah no modo Windows. Este modo é o padrão no Windows.

Se você especificar nocontrol , a saída dos caracteres de controle também será desativada. Essa opção pode fazer sentido quando você estiver baixando URLs cujos nomes contêm caracteres UTF-8 , em um sistema que pode salvar e exibir arquivos no UTF-8 (alguns possíveis valores de bytes usados ​​nas seqüências de bytes UTF-8 se enquadram no intervalo de valores designado pelo wget como “controles”).

O modo ascii é usado para especificar que quaisquer bytes cujos valores estejam fora do intervalo de caracteres ASCII (ou seja, maiores que 127) sejam escapados. Este modo pode ser útil ao salvar nomes de arquivos cuja codificação não corresponde ao usado localmente.

Nenhuma das opções deve ser necessária normalmente. Por padrão, um wget com reconhecimento de IPv6 usará a família de endereços especificada pelo registro DNS do host. Se o DNS responder com endereços IPv4 e IPv6, wgetirá testá-los em sequência até encontrar um ao qual possa se conectar. (Além disso, consulte a opção ” –prefer-family ” descrita abaixo.)

Essas opções podem ser usadas para forçar deliberadamente o uso de famílias de endereços IPv4 ou IPv6 em sistemas com duas famílias, geralmente para ajudar na depuração ou para lidar com configurações de rede quebradas. Somente um de –inet6-only e –inet4-only pode ser especificado ao mesmo tempo. Nenhuma opção está disponível no wget compilado sem suporte ao IPv6.

Isso evita erros espúrios e tenta conectar ao acessar hosts que resolvem endereços IPv6 e IPv4 a partir de redes IPv4. Por exemplo, www.kame.net resolve para 2001: 200: 0: 8002: 203: 47ff: fea5: 3085 e para 203.178.141.194 . Quando a família preferida é ” IPv4 “, o endereço IPv4 é usado primeiro; quando a família preferida é ” IPv6 “, o endereço IPv6 é usado primeiro; se o valor especificado for ” none “, a ordem do endereço retornada pelo DNS será usada sem alterações.

Ao contrário de -4e -6 , essa opção não inibe o acesso a nenhuma família de endereços, apenas altera a ordem em que os endereços são acessados. Observe também que a reordenação realizada por esta opção é estável; isso não afeta a ordem dos endereços da mesma família. Ou seja, a ordem relativa de todos os endereços IPv4 e de todos os endereços IPv6 permanece intacta em todos os casos.

Você pode definir o estado padrão do suporte ao IRI usando o comando ” iri ” em .wgetrc . Essa configuração pode ser substituída na linha de comando.

wget use a função ” nl_langinfo () ” e a variável de ambiente “CHARSET” para obter o código do idioma. Se falhar, o ASCII é usado.

Você pode definir a codificação local padrão usando o comando ” local_encoding ” em .wgetrc . Essa configuração pode ser substituída na linha de comando.

Para HTTP, a codificação remota pode ser encontrada no cabeçalho HTTP ” Content-Type ” e na metatag HTML ” Content-Type http-equiv “.

Você pode definir a codificação padrão usando o comando ” remoteencoding ” em .wgetrc . Essa configuração pode ser substituída na linha de comando.

Pegue, por exemplo, o diretório em ftp://ftp.xemacs.org/pub/xemacs/ . Se você o recupera com -r , ele será salvo localmente em ftp.xemacs.org/pub/xemacs/ . Enquanto a opção -nH pode remover a parte ftp.xemacs.org/ , você ainda está preso ao pub / xemacs , que é onde –cut-dirs é útil; faz com que o wget não “veja” numerar componentes do diretório remoto. Aqui estão vários exemplos de como –cut-dirs opção funciona:

Se você deseja apenas se livrar da estrutura de diretórios, essa opção é semelhante a uma combinação de -nd e -P . No entanto, ao contrário de -nd , –cut-dirs não perde com subdiretórios; por exemplo, com -nH –cut-dirs = 1 , um subdiretório beta / será colocado no xemacs / beta , como seria de esperar.

Observe que os nomes de arquivo alterados dessa maneira serão baixados novamente toda vez que você espelhar um site, porque o wget não pode dizer que o arquivo X.html local corresponde à URL remota X (já que ainda não sabe que o arquivo URL produz saída do tipo text / html ou application / xhtml + xml ).

A partir da versão 1.12, o wget também garantirá que todos os arquivos baixados do tipo text / css terminem no sufixo .css e a opção tenha sido renomeada de –html-extension , para refletir melhor seu novo comportamento. O nome da opção antiga ainda é aceitável, mas agora deve ser considerado reprovado.

Em algum momento no futuro, essa opção poderá ser expandida para incluir sufixos para outros tipos de conteúdo, incluindo tipos de conteúdo que não são analisados ​​pelo wget .

Outra maneira de especificar nome de usuário e senha está no próprio URL. Qualquer um dos métodos revela sua senha para quem se incomoda em executar o ps . Para impedir que as senhas sejam vistas, armazene-as em .wgetrc ou .netrc e proteja esses arquivos de outros usuários com chmod . Se as senhas forem importantes, também não as deixe nos arquivos; edite os arquivos e exclua-os após o wget iniciar o download.

O cache é permitido por padrão.

Você normalmente usa essa opção ao espelhar sites que exigem que você esteja logado para acessar parte ou todo o conteúdo deles. O processo de login normalmente funciona pelo servidor da web que emite um cookie HTTP ao receber e verificar suas credenciais. O cookie é reenviado pelo navegador ao acessar essa parte do site e, assim, comprova sua identidade.

O espelhamento de um site exige que o wget envie os mesmos cookies que o navegador envia ao se comunicar com o site. Para fazer isso, use –load-cookies ; ponto wgetpara o local do arquivo cookies.txt e ele enviará os mesmos cookies que seu navegador enviaria na mesma situação. Navegadores diferentes mantêm os arquivos de cookies de texto em diferentes locais:

Se você não pode usar –load-cookies , ainda pode haver uma alternativa. Se o seu navegador suportar um “gerenciador de cookies”, você poderá usá-lo para visualizar os cookies usados ​​ao acessar o site que você está espelhando. Anote o nome e o valor do cookie e instrua manualmente o wget a enviá-los, ignorando o suporte “oficial” ao cookie:

wget --no-cookies --header "Cookie: <name> = <value>"

Como o formato do arquivo de cookie normalmente não carrega cookies de sessão, o wget os marca com um carimbo de data / hora de expiração de 0 . wget ‘s –load-cookiesreconhece esses cookies como sessão, mas pode confundir outros navegadores. Além disso, observe que os cookies carregados serão tratados como outros cookies de sessão, o que significa que se você quiser –save-cookies para preservá-los novamente, deverá usar –keep-session-cookies novamente.

Com esta opção, o wget ignora o cabeçalho ” Content-Length “, como se nunca tivesse existido.

Você pode definir mais de um cabeçalho adicional especificando –header mais de uma vez.

wget --header = 'Accept-Charset: iso-8859-2' 
     --header = 'Idioma de aceitação: hr' 
     http://fly.srk.fer.hr/

A especificação de uma sequência vazia como o valor do cabeçalho limpará todos os cabeçalhos anteriores definidos pelo usuário.

A partir do wget 1.10, essa opção pode ser usada para substituir os cabeçalhos gerados automaticamente. Este exemplo instrui o wget a se conectar ao host local , mas a especificar foo.bar no cabeçalho ” Host “:

wget --header = "Host: foo.bar" http: // localhost /

Nas versões de wget antes da utilização de tais 1,10 –header causada envio de cabeçalhos duplicados.

Considerações de segurança semelhantes àquelas com –http-password também pertencem aqui.

O protocolo HTTP permite que os clientes se identifiquem usando um campo de cabeçalho ” User-Agent “. Isso permite distinguir o software WWW, geralmente para fins estatísticos ou para rastreamento de violações de protocolo. wget normalmente identifica como ” Wget / versão “, versão sendo o número da versão atual do wget .

No entanto, sabe-se que alguns sites impõem a política de adaptar a saída de acordo com o ” User-Agent“- informações fornecidas. Embora isso não seja uma idéia tão ruim em teoria, ela foi abusada por servidores que negavam informações a clientes que não sejam o Netscape (historicamente) ou, mais frequentemente, o Microsoft Internet Explorer. Esta opção permite alterar a opção” Usuário Linha -Agent “emitida pelo wget . O uso desta opção é desencorajado, a menos que você realmente saiba o que está fazendo. A

especificação do agente do usuário vazio com –user-agent =” “ instrui o wget a não enviar o cabeçalho ” User-Agent ” Solicitações HTTP.

Lembre-se de que o wget precisa saber o tamanho dos dados do POST com antecedência. Portanto, o argumento para ” –post-file ” deve ser um arquivo regular; especificar um FIFO ou algo como / dev / stdinnão vai funcionar. Não está muito claro como solucionar essa limitação inerente ao HTTP / 1.0. Embora o HTTP / 1.1 introduza transferência em partes que não exija o conhecimento prévio da duração da solicitação, um cliente não pode usá-las, a menos que saiba que está falando com um servidor HTTP / 1.1. E não é possível saber até que receba uma resposta, que por sua vez exige que a solicitação seja concluída, o que é uma espécie de problema de galinha e ovo.

Observe que, se o wget for redirecionado após a conclusão da solicitação POST, ele não enviará os dados do POST para o URL redirecionado. Como os URLs que processam o POST geralmente respondem com um redirecionamento para uma página comum, que não deseja ou aceita o POST. Não está completamente claro que esse comportamento é ótimo; se não der certo, pode ser alterado no futuro.

Este exemplo mostra como efetuar logon em um servidor usando o POST e, em seguida, continue com o download das páginas desejadas, presumivelmente acessíveis apenas a usuários autorizados. Primeiro, efetuamos login no servidor, o que pode ser feito apenas uma vez.

wget --save-cookies cookies.txt --post-data 
     'user = foo & password = bar' http://server.com/auth.php

E então agarramos a página (ou páginas) com que nos preocupamos:

wget --load-cookies cookies.txt 
     -p http://server.com/interesting/article.php

Se o servidor estiver usando cookies de sessão para rastrear a autenticação do usuário, o procedimento acima não funcionará porque –save-cookies não os salvará (e nem os navegadores) e o arquivo cookies.txt estará vazio. Nesse caso, use –keep-session-cookies junto com –save-cookies para forçar o salvamento dos cookies da sessão.

Esta opção é útil para alguns programas CGI de download de arquivos que usam cabeçalhos ” Disposição de Conteúdo ” para descrever qual deve ser o nome de um arquivo baixado.

O uso desta opção não é recomendado e destina-se apenas a suportar alguns servidores obscuros, que nunca enviam desafios de autenticação HTTP, mas aceitam informações de autenticação não solicitadas, por exemplo, além da autenticação baseada em formulário.

A especificação de SSLv2, SSLv3 ou TLSv1 força o uso do protocolo correspondente. Essa opção é útil ao conversar com implementações de servidor SSL antigas e com erros que dificultam a escolha do OpenSSL para a versão correta do protocolo. Felizmente, esses servidores são bastante raros.

No wget 1.10, o padrão é verificar o certificado do servidor contra as autoridades de certificação reconhecidas, interrompendo o handshake SSL e interrompendo o download se a verificação falhar. Embora isso ofereça downloads mais seguros, ele interrompe a interoperabilidade com alguns sites que funcionavam com versões anteriores do wget , particularmente aqueles que usam certificados autoassinados, expirados ou inválidos. Esta opção força um modo de operação “inseguro” que transforma os erros de verificação do certificado em avisos e permite que você continue.

Se você encontrar erros de “verificação de certificado” ou aqueles que dizem que “nome comum não corresponde ao nome do host solicitado”, você pode usar esta opção para ignorar a verificação e prosseguir com o download. Use essa opção apenas se estiver convencido da autenticidade do site ou se realmente não se importa com a validade do certificado. Quase sempre é uma má idéia não verificar os certificados ao transmitir dados confidenciais ou importantes.

Sem essa opção, o wget procura certificados CA nos locais especificados pelo sistema, escolhidos no momento da instalação do OpenSSL.

Sem essa opção, o wget procura certificados CA nos locais especificados pelo sistema, escolhidos no momento da instalação do OpenSSL.

Nesses sistemas, a biblioteca SSL precisa de uma fonte externa de aleatoriedade para inicializar. A aleatoriedade pode ser fornecida pelo EGD (consulte –egd-file abaixo) ou lida a partir de uma fonte externa especificada pelo usuário. Se essa opção não for especificada, o wget procurará dados aleatórios em $ RANDFILE ou, se não estiver definido , em $ HOME / .rnd . Se nenhum desses estiver disponível, é provável que a criptografia SSL não seja utilizável.

Se você estiver recebendo o “Não foi possível propagar o OpenSSL PRNG; desabilitando o SSL”. erro, você deve fornecer dados aleatórios usando alguns dos métodos descritos acima.

O OpenSSL permite ao usuário especificar sua própria fonte de entropia usando a variável de ambiente “RAND_FILE”. Se essa variável não estiver definida, ou se o arquivo especificado não produzir aleatoriedade suficiente, o OpenSSL lerá dados aleatórios do soquete EGD especificado usando esta opção.

Se esta opção não for especificada (e o comando de inicialização equivalente não for usado), o EGD nunca será contatado. O EGD não é necessário em sistemas Unix modernos que suportam/ dev / aleatório .

Outra maneira de especificar nome de usuário e senha está no próprio URL. Qualquer um dos métodos revela sua senha para quem se incomoda em executar o ps . Para impedir que as senhas sejam vistas, armazene-as em .wgetrc ou .netrc e proteja esses arquivos de outros usuários com chmod . Se as senhas forem importantes, também não as deixe nos arquivos; edite os arquivos e exclua-os após o wget iniciar o download.

Observe que, apesar de o wget gravar em um nome de arquivo conhecido para esse arquivo, isso não é um problema de segurança no cenário de um usuário criar .listing um link simbólico para / etc / passwd ou algo assim e solicitar ao root para executar o wget em seu diretório. Dependendo das opções usadas, o wgetse recusará a gravar em .listing , fazendo com que a operação de globbing / recursão / registro de hora falhe, ou o link simbólico será excluído e substituído pelo arquivo .listing real ou a listagem será gravada em um arquivo .listing.number.

Embora essa situação não seja um problema, o root nunca deve executar o wget em um diretório de usuário não confiável. Um usuário pode fazer algo tão simples quanto vincular index.html a / etc / passwd e solicitar que o root execute o wget com -N ou -r, para que o arquivo seja substituído.

wget ftp://gnjilux.srk.fer.hr/*.msg

Por padrão, o globbing será ativado se o URL contiver um caractere globbing. Esta opção pode ser usada para ativar ou desativar permanentemente o globbing.

Pode ser necessário citar o URL para evitar que ele seja expandido pelo seu shell . Globbing faz com que o wget procure uma lista de diretórios, que é específica do sistema. É por isso que atualmente funciona apenas com servidores FTP Unix (e aqueles que emulam a saída ls do Unix ).

Se a máquina estiver conectada diretamente à Internet, o FTP passivo e o ativo deverão funcionar igualmente bem. Por trás da maioria das configurações de firewall e NAT, o FTP passivo tem mais chances de funcionar. No entanto, em algumas configurações raras de firewall, o FTP ativo realmente funciona quando o FTP passivo não. Se você suspeita que seja esse o caso, use esta opção ou defina ” passive_ftp = off ” no seu arquivo init.

Quando –retr-symlinks é especificado, no entanto, links simbólicos são percorridos e os arquivos apontados são recuperados. No momento, essa opção não faz com que o wget passe links simbólicos para diretórios e recorra a eles, mas no futuro deve ser aprimorado para fazer isso.

Observe que, ao recuperar um arquivo (não um diretório) porque foi especificado na linha de comando, e não porque foi repetido, essa opção não tem efeito. Links simbólicos são sempre atravessados ​​neste caso.

wget -r -nd --delete-after http://whatever.com/~popular/page/

A opção -r é recuperar recursivamente e -nd para não criar diretórios.

Observe que –delete-after exclui arquivos na máquina local. Não emite o comando DELE FTP para sites FTP remotos, por exemplo. Além disso, observe que quando –delete-after é especificado, –convert-links é ignorado, portanto, os arquivos .orig não são criados em primeiro lugar.

1. Os links para os arquivos que foram baixados pelo wget serão alterados para se referir ao arquivo para o qual apontam como um link relativo. Exemplo: se o arquivo baixado /foo/doc.html vincular a /bar/img.gif , também baixou, o link em doc.htmlserá modificado para apontar para ../bar/img.gif . Esse tipo de transformação funciona de maneira confiável para combinações arbitrárias de diretórios.

2. Os links para arquivos que não foram baixados pelo wget serão alterados para incluir o nome do host e o caminho absoluto do local para o qual eles apontam. Exemplo: se o arquivo baixado /foo/doc.html vincular a /bar/img.gif (ou a ../bar/img.gif ), o link em doc.html será modificado para apontar para http: // nome do host / bar / img.gif .

Por esse motivo, a navegação local funciona de maneira confiável: se um arquivo vinculado foi baixado, o link fará referência ao seu nome local; se não tiver sido baixado, o link fará referência ao endereço completo da Internet, em vez de apresentar um link quebrado. O fato de os links anteriores serem convertidos em links relativos garante que você possa mover a hierarquia baixada para outro diretório.

Note-se que só no fim do download pode wget saber quais links foram baixados. Por isso, o trabalho realizado por -k será executado no final de todos os downloads.

Por exemplo, digamos que o documento 1.html contenha um < IMG> tag referenciando 1.gif e um <A>tag apontando para o documento externo 2.html . Digamos que 2.html seja semelhante, mas que sua imagem seja 2.gif e esteja vinculada a 3.html . Digamos que isso continue até um número arbitrariamente alto.

Se alguém executar o comando:

wget -r -l 2 http: // <site> /1.html

então 1.html , 1.gif , 2.html , 2.gif e 3.html serão baixados. Como você pode ver, 3.html não possui seu requisito 3.gif, porque o wget está contando o número de saltos (até 2) para 1.html para determinar onde parar a recursão. No entanto, com este comando:

wget -r -l 2 -p http: // <site> /1.html

todos os arquivos acima e 3.html requisito ‘s 3.gif será baixado. Similarmente,

wget -r -l 1 -p http: // <site> /1.html

fará com que 1.html , 1.gif , 2.html e 2.gif sejam baixados. Pode-se pensar que:

wget -r -l 0 -p http: // <site> /1.html

baixaria apenas 1.html e 1.gif , mas infelizmente esse não é o caso, porque -l 0 é equivalente a -l inf ; isto é, recursão infinita. Para baixar uma única página HTML (ou algumas delas, todas especificadas na linha de comando ou em um arquivo de entrada -i- URL) e seus (ou seus) requisitos, deixe -r e -l :

wget -p http: // <site> /1.html

Observe que o wget se comportará como se -r tivesse sido especificado, mas apenas essa página e seus requisitos serão baixados. Os links dessa página para documentos externos não serão seguidos. Na verdade, para baixar uma única página e todos os seus requisitos (mesmo que existam em sites separados) e garantir que o lote seja exibido corretamente localmente, esse autor gosta de usar algumas opções além de -p :

wget -E -H -k -K -p http: // <site> / <documento>

Para finalizar este tópico, vale a pena saber que a idéia do wget de um link de documento externo é qualquer URL especificado em uma tag <A> , <AREA> ou <LINK> diferente de ” <LINK REL =” folha de estilo “> .

De acordo com as especificações, os comentários em HTML são expressos como declarações SGML . Declaração é uma marcação especial que começa com <! e termina com > , como <! DOCType …> , que pode conter comentários entre um par de – delimitadores . Comentários HTML são “declarações vazias”, declarações SGML sem nenhum texto que não seja de comentário. Portanto, <! – foo -> é um comentário válido, assim como <! – one– –wo -> , mas <! – 1–2 -> não é.

Por outro lado, a maioria dos criadores de HTML não vê comentários como algo além do texto delimitado por <! – e -> , que não é exatamente o mesmo. Por exemplo, algo como <! ————> funciona como um comentário válido, desde que o número de traços seja um múltiplo de quatro. Caso contrário, o comentário tecnicamente dura até o próximo – , que pode estar na outra extremidade do documento. Por esse motivo, muitos navegadores populares ignoram completamente a especificação e implementam o que os usuários esperam: comentários delimitados com <! – e -> .

Até a versão 1.9, o wgetinterpretou os comentários estritamente, o que resultou na falta de links em muitas páginas da web que eram exibidas bem nos navegadores, mas tiveram o infortúnio de conter comentários não compatíveis. A partir da versão 1.9, o wget se juntou às fileiras de clientes que implementam comentários “ingênuos ”, encerrando cada comentário na primeira ocorrência de -> .

Se, por qualquer motivo, você desejar uma análise estrita de comentários , use esta opção para ativá-lo em.

No passado, essa opção era a melhor aposta para baixar uma única página e seus requisitos, usando uma linha de comando como:

wget --ignore-tags = a, área -H -k -K -r http: // <site> / <documento>

No entanto, o autor desta opção encontrou uma página com tags como ” <LINK REL =” home “HREF =” / “> ” e chegou à conclusão de que especificar tags para ignorar não era suficiente. Não se pode simplesmente dizer ao wget para ignorar ” <LINK> “, porque as folhas de estilo não serão baixadas. Agora, a melhor opção para baixar uma única página e seus requisitos é a opção –página-requisitos .