Чаму os.system("unset http_proxy") нічога не змяняе

Выдаліце зменную проксі з патрэбнага працэсу Python або перадайце дачэрняй камандзе кантраляванае асяроддзе.

Наступныя выклікі ствараюць два асобныя працэсы 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-кліенты, якія ўжо захавалі свае налады.

API subprocess дакументуе аргумент env, а os.environ апісвае асяроддзе працэсу Python. Менавіта з-за гэтых межаў каманда shell можа паведаміць пра поспех, а наступны запыт усё яшчэ выкарыстоўвае стары проксі.

Нарэшце, праверце кліент, які вы насамрэч запускаеце. Зменныя асяроддзя — гэта адзін уваход канфігурацыі. Яўная опцыя проксі або ўласная канфігурацыя праграмы могуць працягваць выбіраць проксі пасля знікнення гэтых зменных.

Падобныя артыкулы