Pourquoi exécuter set-proxy.sh ne modifie pas votre terminal

Votre script contient la bonne ligne export https_proxy=.... Vous l'exécutez, et la commande suivante voit toujours l'ancien proxy. Le script a peut-être parfaitement fonctionné dans son propre processus.

Exécuter un script démarre un shell distinct. Il peut transmettre des variables aux commandes qu'il lance, mais il ne peut pas remplacer l'environnement du shell parent du terminal après sa sortie.

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

Ce sont deux opérations différentes. La seconde utilise le builtin dot du shell pour lire le fichier dans le shell courant. Bash l'appelle aussi source ; voir sa référence des builtins.

Ne chargez avec source qu'un fichier auquel vous faites confiance, car toutes ses commandes shell s'exécutent dans ce contexte courant. Si le proxy ne sert qu'aux commandes à l'intérieur du script, l'exécution ordinaire est la bonne limite. Pour une seule commande externe, une affectation de proxy limitée à la commande évite de modifier le shell courant.

Gardez les affectations de variables littérales. Les accents graves signifient une substitution de commande, pas une citation. Une ligne qui affecte un proxy ne doit pas tenter d'exécuter son URL par accident. Pour les valeurs destinées à choisir un point de terminaison public, la liste de proxys gratuits fournit des candidats dont le protocole doit correspondre au client. Enfin, vérifiez les noms de variables que lit le véritable client réseau ; corriger la portée du shell ne rend pas effective une variable non prise en charge.