Perché eseguire set-proxy.sh non cambia il tuo terminale

Il tuo script contiene la riga export https_proxy=... corretta. Lo esegui, e il comando successivo vede ancora il vecchio proxy. Forse lo script ha funzionato perfettamente dentro il proprio processo.

Eseguire uno script avvia uno shell separato. Può passare variabili ai comandi che avvia, ma non può sostituire l'ambiente dello shell padre del terminale dopo la sua uscita.

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

Sono operazioni diverse. La seconda usa il builtin dot dello shell per leggere il file nello shell corrente. Bash lo chiama anche source; vedi il riferimento dei builtin.

Carica con source solo un file di cui ti fidi, perché tutti i suoi comandi shell vengono eseguiti in questo contesto corrente. Se il proxy serve solo ai comandi dentro lo script, l'esecuzione ordinaria è il confine corretto. Per un singolo comando esterno, un'assegnazione proxy limitata al comando evita di cambiare lo shell corrente.

Mantieni letterali le assegnazioni delle variabili. Gli accenti gravi significano sostituzione di comando, non citazione. Una riga che assegna un proxy non dovrebbe tentare di eseguire il proprio URL per errore. Per i valori destinati a scegliere un endpoint pubblico, la lista dei proxy gratuiti fornisce candidati il cui protocollo deve corrispondere al client. Infine, verifica i nomi delle variabili che legge il client di rete reale; correggere l'ambito dello shell non rende efficace una variabile non supportata.