Wget trenger en proxyadresse, ikke en PAC-URL
En nettleser kan evaluere et PAC-skript automatisk, mens GNU Wget forventer et faktisk proxyendepunkt i proxyinnstillingene.
Gi GNU Wget et faktisk videresendingsendepunkt for nedlastingsmålet:
https_proxy=http://proxy.example:8080 wget https://downloads.example/file.zipErstatt den første eksempel-URL-en med den godkjente HTTP-proxyen og den andre med den tiltenkte filen. https_proxy velger forespørsler til HTTPS-mål; verdien angir lytteren, ikke et PAC-skript som skal evalueres.
En URL som https://config.example/proxy.pac peker på data for rutevalg. Å sette den i proxyvariabelen ber ikke Wget om å kjøre JavaScript. Sjekk GNU Wgets proxyinndata og den installerte versjonen; et annet verktøy med lignende navn kan oppføre seg annerledes.
Hent PAC-resultatet for de aktuelle URL-ene. Å kopiere ett endepunkt er bare passende når den ruten gjelder gjennom hele operasjonen. Omdirigeringer kan endre verter, og interne mål kan være direkte. En kompleks policy trenger en støttet adapter eller en administrasjonsordning som bevarer disse beslutningene.
Be om det godkjente endepunktet eller kommandolinjeintegrasjon i stedet for å lime PAC-programmet inn i en shell-profil eller kjøre et ukjent skript som ubegrenset shell-kode.