কেন os.system("unset http_proxy") কিছুই বদলায় না

নিচের কলগুলো দুটি আলাদা shell প্রক্রিয়া তৈরি করে:

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

প্রথম shell নিজের পরিবেশ থেকে একটি ভেরিয়েবল সরিয়ে বেরিয়ে যায়। Python প্রক্রিয়ায় মূল মানটি এখনও থাকে। দ্বিতীয় shell সেটি আবার উত্তরাধিকার সূত্রে পায়।

চাইল্ডকে আপনি যে পরিবেশ চেয়েছিলেন সেটি দিন

যখন কেবল একটি কমান্ড উত্তরাধিকারসূত্রে পাওয়া প্রক্সি ভেরিয়েবল ছাড়া চলা উচিত, তখন 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-এর প্রক্রিয়া পরিবেশ বর্ণনা করে। এই পরিধিগুলোর কারণেই একটি shell কমান্ড সফলতার কথা জানাতে পারে অথচ পরের অনুরোধটি এখনও পুরোনো প্রক্সি ব্যবহার করে।

সবশেষে, আপনি আসলে যে ক্লায়েন্ট চালাচ্ছেন সেটি পরীক্ষা করুন। পরিবেশ ভেরিয়েবল হলো একটি কনফিগারেশন ইনপুট। একটি স্পষ্ট প্রক্সি অপশন বা অ্যাপ্লিকেশনের নিজস্ব কনফিগারেশন ওই ভেরিয়েবলগুলো চলে যাওয়ার পরেও প্রক্সি বেছে নেওয়া চালিয়ে যেতে পারে।