რატომ 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 ბრძანებამ შეიძლება წარმატება შეატყობინოს, მაშინ როცა შემდეგი მოთხოვნა ჯერ კიდევ ძველ პროქსის იყენებს.

საბოლოოდ, შეამოწმეთ კლიენტი, რომელსაც რეალურად აშვებთ. გარემოს ცვლადები კონფიგურაციის ერთი შეყვანაა. გამოკვეთილი პროქსი პარამეტრი ან აპლიკაციის საკუთარი კონფიგურაცია შეიძლება გააგრძელოს პროქსის არჩევა მას შემდეგ, რაც ეს ცვლადები გაქრა.