एउटा shell कमाण्डका लागि फरक प्रोक्सी प्रयोग गर्नुहोस्
अभिभावक 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 ले वातावरण फिल्टर गर्न सक्छ भन्ने सम्झनुहोस्; बाह्य कमाण्डलाई देखिने भेरिएबल स्वतः हरेक विशेषाधिकार सीमाबाट जाँदैन। अस्थायी दायरा र वास्तविक प्रोक्सी छनोट अलग प्रश्न नै रहन्छन्।