Hvorfor kørsel af set-proxy.sh ikke ændrer din terminal

Dit script indeholder den rigtige export https_proxy=...-linje. Du kører det, og den næste kommando ser stadig den gamle proxy. Scriptet har måske fungeret perfekt inde i sin egen proces.

Kørsel af et script starter en separat shell. Den kan sende variabler videre til de kommandoer, den starter, men den kan ikke erstatte miljøet i terminalshellen, der er forælder, efter at den afsluttes.

./set-proxy.sh
. ./set-proxy.sh

Det er forskellige operationer. Den anden bruger shellens dot-builtin til at læse filen i den aktuelle shell. Bash kalder det også source; se dens builtin-reference.

Source kun en fil, du har tillid til, fordi alle dens shell-kommandoer kører i netop den aktuelle kontekst. Hvis proxyen kun skal bruges til kommandoer inde i scriptet, er almindelig kørsel den rigtige grænse i stedet. Til en enkelt ekstern kommando undgår en kommandobunden proxy-tildeling at ændre den aktuelle shell.

Hold variabeltildelinger bogstavelige. Backticks betyder kommandoerstatning, ikke citat. En linje, der tildeler en proxy, bør ikke ved et uheld forsøge at køre sin URL. For værdier, der skal vælge et offentligt endepunkt, leverer listen over gratis proxyer kandidater, hvis protokol skal passe til klienten. Kontroller til sidst de variabelnavne, som den faktiske netværksklient læser; at rette shellens omfang gør ikke en ikke-understøttet variabel effektiv.