Varför körning av set-proxy.sh inte ändrar din terminal

Ditt skript innehåller den korrekta export https_proxy=...-raden. Du kör det, och nästa kommando ser fortfarande den gamla proxy:n. Skriptet kan ha fungerat perfekt inne i sin egen process.

Att köra ett skript startar ett separat skal. Det kan skicka variabler vidare till kommandona det startar, men det kan inte ersätta miljön i föräldraskalet för terminalen när det avslutas.

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

Det är olika operationer. Den andra använder skalets inbyggda dot-kommando för att läsa filen i det aktuella skalet. Bash kallar det också source; se referensen för inbyggda kommandon.

Sourcea bara en fil du litar på, eftersom alla dess skalkommandon körs i just den aktuella kontexten. Om proxy:n bara behövs för kommandon inne i skriptet är vanlig körning den riktiga gränsen. För ett enda externt kommando undviker en kommandobunden proxy-tilldelning att ändra det aktuella skalet.

Håll variabeltilldelningar bokstavliga. Backticks betyder kommandoersättning, inte citat. En rad som tilldelar en proxy bör inte av misstag försöka köra sin URL. För värden som ska välja en offentlig slutpunkt tillhandahåller listan över gratisproxyer kandidater vars protokoll måste matcha klienten. Kontrollera slutligen variabelnamnen som den faktiska nätverksklienten läser; att rätta skalets omfång gör inte en variabel som inte stöds effektiv.