एक shell कमांड के लिए अलग प्रॉक्सी इस्तेमाल करें

आप चाहते हैं कि एक डाउनलोड किसी अलग प्रॉक्सी का उपयोग करे और उसके बाद सब कुछ सामान्य हो जाए। अपनी shell की स्टार्टअप फ़ाइल संपादित करके यह उम्मीद करने की ज़रूरत नहीं है कि आप उसे पूर्ववत करना याद रखेंगे।

POSIX-शैली की shell में बाहरी कमांड के लिए, कमांड से पहले असाइनमेंट रखें:

https_proxy=http://proxy.example:8080 curl https://example.com/

उस डाउनलोड के लिए इरादा किया गया HTTP एंडपॉइंट इस्तेमाल करें; HTTP प्रॉक्सी सूची अनुमत सार्वजनिक मार्गों के लिए उम्मीदवार देती है। असाइनमेंट उस कमांड के वातावरण को दिया जाता है। उसकी चाइल्ड प्रक्रियाएँ मान विरासत में ले सकती हैं, लेकिन कमांड समाप्त होने के बाद असाइनमेंट मूल shell के मौजूदा मान को नहीं बदलता।

क्लाइंट अब भी तय करता है कि क्या पढ़ा जाए

shell सिंटैक्स एक वातावरण बनाता है; यह नेटवर्क मार्ग को बाध्य नहीं करता। वे वेरिएबल नाम इस्तेमाल करें जिन्हें एप्लिकेशन समर्थित करता है। मौजूदा बायपास वेरिएबल, स्पष्ट कमांड विकल्प या एप्लिकेशन का अपना कॉन्फ़िगरेशन परिणाम को अब भी प्रभावित कर सकते हैं।

Bash पर्यावरण दस्तावेज़ कमांड-उपसर्ग के व्यवहार को समझाता है। जो कमांड shell फ़ंक्शन, विशेष बिल्टइन या shell सिंटैक्स हैं, उनके अतिरिक्त दायरे के नियम हो सकते हैं, इसलिए ऊपर का सरल उदाहरण जानबूझकर बाहरी प्रोग्राम का उपयोग करता है।

कई कमांड के लिए, सबशेल इस्तेमाल करें

(
  export http_proxy=http://proxy.example:8080
  export https_proxy=http://proxy.example:8080
  command-one
  command-two
)

कोष्ठक में बंद समूह अपने स्वयं के shell वातावरण के साथ चलता है। उदाहरण के कमांड नामों को उन प्रोग्रामों से बदलें जिन्हें आप चलाना चाहते हैं। यह पैटर्न पुराना मान सहेजने, उसे अधिलेखित करने और हर संभावित विफलता के बाद उसे हाथ से बहाल करने के नाज़ुक क्रम से बचता है।

shell इतिहास में कॉपी किए गए उदाहरणों से रहस्य दूर रखें। यह भी याद रखें कि sudo वातावरण को फ़िल्टर कर सकता है; बाहरी कमांड को दिखने वाला वेरिएबल स्वचालित रूप से हर विशेषाधिकार सीमा से नहीं गुज़रता। अस्थायी दायरा और वास्तविक प्रॉक्सी चयन अलग प्रश्न बने रहते हैं।