os.system("unset http_proxy") कुछ भी क्यों नहीं बदलता

निम्नलिखित कॉल दो अलग शेल प्रक्रियाएँ बनाते हैं:

os.system('unset http_proxy')
os.system('curl https://example.com/')

पहला शेल अपने परिवेश से एक चर हटाता है और समाप्त हो जाता है। Python प्रक्रिया के पास अभी भी मूल मान है। दूसरा शेल उसे फिर से विरासत में लेता है।

बच्चे को वही परिवेश दें जो आपका इरादा था

जब केवल एक कमांड को विरासत में मिले प्रॉक्सी चर के बिना चलना हो, तो Python का परिवेश प्रतिलिपि करें और प्रतिलिपि बच्चे को दें:

import os
import subprocess

env = os.environ.copy()
for name in ('http_proxy', 'https_proxy', 'all_proxy',
             'HTTP_PROXY', 'HTTPS_PROXY', 'ALL_PROXY'):
    env.pop(name, None)
subprocess.run(['curl', '--proxy', '', 'https://example.com/'],
               env=env, check=True)

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

Python प्रक्रिया में बाद के संचालनों के लिए, os.environ को जानबूझकर बदलें। यह प्रभावित करता है कि नव निर्मित बच्चे क्या विरासत में लेते हैं; यह मूल टर्मिनल के परिवेश को फिर से नहीं लिखता और जिन HTTP क्लाइंट्स ने पहले ही अपनी सेटिंग्स कैप्चर कर ली हैं उन्हें जरूरी नहीं कि पुनः कॉन्फ़िगर करे।

subprocess API env तर्क का दस्तावेज़ीकरण करता है, और os.environ Python के प्रक्रिया परिवेश का वर्णन करता है। ये क्षेत्र ही कारण हैं कि एक शेल कमांड सफलता की रिपोर्ट कर सकता है जबकि अगला अनुरोध अभी भी पुराने प्रॉक्सी का उपयोग करता है।

अंत में, उस क्लाइंट की जाँच करें जिसे आप वास्तव में चला रहे हैं। परिवेश चर एक कॉन्फ़िगरेशन इनपुट हैं। एक स्पष्ट प्रॉक्सी विकल्प या किसी एप्लिकेशन का अपना कॉन्फ़िगरेशन उन चरों के चले जाने के बाद भी प्रॉक्सी चुनना जारी रख सकता है।