Wget लाई प्रोक्सी ठेगाना चाहिन्छ, PAC URL होइन
ब्राउजरले PAC स्क्रिप्ट स्वचालित रूपमा मूल्याङ्कन गर्न सक्छ, जबकि GNU Wget ले आफ्नो प्रोक्सी सेटिङमा वास्तविक प्रोक्सी एन्डपोइन्ट अपेक्षा गर्छ।
डाउनलोड गन्तव्यका लागि GNU Wget लाई वास्तविक फर्वार्डिङ एन्डपोइन्ट दिनुहोस्:
https_proxy=http://proxy.example:8080 wget https://downloads.example/file.zipपहिलो उदाहरण URL लाई स्वीकृत HTTP प्रोक्सीले र दोस्रोलाई इच्छित फाइलले बदल्नुहोस्। https_proxy ले HTTPS गन्तव्यका अनुरोधहरू छान्छ; यसको मानले सुन्नेलाई जनाउँछ, मूल्याङ्कन गर्नुपर्ने PAC स्क्रिप्टलाई होइन।
https://config.example/proxy.pac जस्तो URL ले मार्ग-छनोट डेटालाई सङ्केत गर्छ। यसलाई प्रोक्सी चरमा राख्दा Wget लाई JavaScript चलाउन भनिँदैन। GNU Wget का प्रोक्सी इनपुटहरू र स्थापित संस्करण जाँच्नुहोस्; समान नामको अर्को उपकरणले फरक व्यवहार गर्न सक्छ।
सम्बन्धित URL का लागि PAC नतिजा प्राप्त गर्नुहोस्। एउटा एन्डपोइन्ट प्रतिलिपि गर्नु त्यतिबेला मात्र उपयुक्त हुन्छ जब त्यो मार्ग सम्पूर्ण कार्यभरि लागू हुन्छ। रिडाइरेक्टले होस्ट बदल्न सक्छ, र आन्तरिक गन्तव्य सिधा हुन सक्छ। जटिल नीतिका लागि ती निर्णय जोगाउने समर्थित एडाप्टर वा व्यवस्थापन व्यवस्था चाहिन्छ।
PAC कार्यक्रम shell प्रोफाइलमा टाँस्ने वा अपरिचित स्क्रिप्टलाई असीमित shell कोडका रूपमा चलाउने सट्टा स्वीकृत एन्डपोइन्ट वा कमाण्ड-लाइन एकीकरण माग्नुहोस्।