De ce rularea set-proxy.sh nu îți schimbă terminalul

Scriptul tău conține linia export https_proxy=... corectă. Îl rulezi, iar comanda următoare vede în continuare proxy-ul vechi. Poate că scriptul a funcționat perfect în interiorul propriului proces.

Rularea unui script pornește un shell separat. Acesta poate transmite variabile comenzilor pe care le pornește, dar nu poate înlocui mediul shell-ului părinte al terminalului după ce se termină.

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

Sunt operațiuni diferite. A doua folosește builtin-ul dot al shell-ului pentru a citi fișierul în shell-ul curent. Bash îl numește și source; vezi referința builtin-urilor.

Fă source doar pentru un fișier în care ai încredere, pentru că toate comenzile sale de shell rulează în acel context curent. Dacă proxy-ul este necesar doar pentru comenzile din interiorul scriptului, execuția obișnuită este limita corectă. Pentru o singură comandă externă, o atribuire de proxy limitată la comandă evită modificarea shell-ului curent.

Păstrează atribuirile de variabile literale. Backtick-urile înseamnă substituție de comandă, nu citare. O linie care atribuie un proxy nu ar trebui să încerce din greșeală să execute URL-ul său. Pentru valorile destinate alegerii unui endpoint public, lista de proxy-uri gratuite oferă candidați al căror protocol trebuie să corespundă clientului. În final, verifică numele variabilelor pe care le citește clientul de rețea real; repararea domeniului shell-ului nu face o variabilă neacceptată eficientă.