Waarom set-proxy.sh uitvoeren je terminal niet verandert
Een uitgevoerd script kan variabelen niet terug naar zijn oudershell exporteren. Laad met source een vertrouwd configuratiebestand wanneer de huidige shell de instellingen moet behouden.
Je script bevat de juiste export https_proxy=...-regel. Je voert het uit, en de volgende opdracht ziet nog steeds de oude proxy. Misschien werkte het script binnen zijn eigen proces perfect.
Een script uitvoeren start een aparte shell. Die kan variabelen doorgeven aan de opdrachten die hij start, maar kan de omgeving van de bovenliggende terminalshell na afloop niet vervangen.
./set-proxy.sh
. ./set-proxy.sh
Dat zijn verschillende bewerkingen. De tweede gebruikt de dot-builtin van de shell om het bestand in de huidige shell te lezen. Bash noemt dit ook source; zie de builtin-referentie.
Laad met source alleen een bestand dat je vertrouwt, want al zijn shellopdrachten draaien in die huidige context. Is de proxy alleen nodig voor opdrachten binnen het script, dan is gewoon uitvoeren de juiste grens. Voor één externe opdracht vermijdt een opdrachtgebonden proxytoewijzing dat de huidige shell verandert.
Houd variabeletoewijzingen letterlijk. Backticks betekenen opdrachtvervanging, niet aanhaling. Een regel die een proxy toewijst, moet niet per ongeluk zijn URL proberen uit te voeren. Voor waarden die een openbaar eindpunt moeten kiezen, levert de lijst met gratis proxy's kandidaten waarvan het protocol bij de client moet passen. Controleer ten slotte de variabelenamen die de echte netwerkclient leest; het bereik van de shell repareren maakt een niet-ondersteunde variabele niet effectief.