Risposte:
Non esiste un'autorità centrale che assegni un significato ufficiale alle variabili di ambiente prima che le applicazioni possano utilizzarle. POSIX definisce il significato di alcune variabili ( PATH
, TERM
, ...) e le liste di molti altri in un modo non-normativo ad essere di uso comune, tutti in maiuscolo. http_proxy
e gli amici non sono tra questi.
Diversamente praticamente tutte le variabili d'ambiente convenzionali utilizzati da molte applicazioni, http_proxy
, https_proxy
, ftp_proxy
e no_proxy
sono comunemente minuscole. Non ricordo alcun programma che li capisca solo in maiuscolo, non riesco nemmeno a trovarne uno che li provi in maiuscolo. Molti programmi usano solo la variante minuscola, tra cui lince, wget, curl, perl LWP, perl WWW :: Search, python urllib / urllib2, ecc. Quindi per queste variabili, la forma giusta è quella minuscola.
Il nome minuscolo risale almeno al libern CERN 2.15 di marzo 1994 (grazie a Stéphane Chazelas per averlo individuato). Non so cosa abbia motivato la scelta del minuscolo, che sarebbe stato insolito anche allora.
HTTPS_PROXY
. la finestra mobile utilizza anche la variante maiuscola.
sudo -E apt-add-repository ppa:xxxxx/xxxx
. ho dovuto unset https_proxy
eexport HTTPS_PROXY=http://a.b.c.d:xxxx
Non esiste uno standard e vengono utilizzate entrambe le versioni maiuscole e minuscole a seconda dell'applicazione (vedere anche HTTPS_PROXY, ALL_PROXY, NO_PROXY).
Per esempio:
arricciare
ENVIRONMENT VARIABLES
Curl reads and understands the following environment variables:
http_proxy, HTTPS_PROXY, FTP_PROXY
They should be set for protocol-specific proxies. General proxy should be
set with
ALL_PROXY
A comma-separated list of host names that shouldn't go through any proxy is
set in (only an asterisk, '*' matches all hosts)
NO_PROXY
idiota
http.proxy
Override the HTTP proxy, normally configured using the http_proxy, https_proxy,
and all_proxy environment variables (see curl(1)). [..]
Pitone
urllib.request.getproxies()
supporta entrambe le varianti minuscole e maiuscole.
Menziona anche un problema di sicurezza:
Se è impostata la variabile di ambiente REQUEST_METHOD, che di solito indica che lo script è in esecuzione in un ambiente CGI, la variabile di ambiente HTTP_PROXY (maiuscola _PROXY) verrà ignorata. Questo perché quella variabile può essere iniettata da un client usando l'intestazione HTTP “Proxy:”. Se è necessario utilizzare un proxy HTTP in un ambiente CGI, utilizzare ProxyHandler in modo esplicito o assicurarsi che il nome della variabile sia in minuscolo (o almeno il suffisso _proxy).
Alcune applicazioni consentono NO_PROXY
di contenere stelle / intervalli IP mentre altre no.
Così
export https_proxy=$http_proxy HTTP_PROXY=$http_proxy HTTPS_PROXY=$http_proxy NO_PROXY=$no_proxy
dovresti averti coperto.
La convenzione prevede l'uso di tutte le variabili di ambiente capps durante l'esportazione, in modo che quando si scrivono script di shell sia possibile utilizzare nomi di variabili minuscole senza preoccuparsi delle collisioni di nomi con altri programmi. Naturalmente questa è solo una convenzione, non ci sono restrizioni tecniche sulla limitazione dei nomi delle variabili di ambiente, quindi in alcuni casi potrebbe essere utilizzata la versione minuscola, ma la migliore pratica è maiuscola e ricorda che sono sensibili al maiuscolo / minuscolo, quindi potrebbero avere differenti valori.
http_proxy
e i suoi fratelli sono generalmente minuscoli.
http_proxy
e gli amici deve essere scritto in minuscolo, in violazione di una convenzione. Per un'applicazione da utilizzare HTTP_PROXY
sarebbe un bug perché sarebbe incompatibile con il resto del mondo.
Unlike basically all conventional environment variables used by many applications, http_proxy, https_proxy, ftp_proxy and no_proxy are commonly lowercase. I don't recall any program that only understands them in uppercase
-> Per la cronaca, ho appena scoperto che la finestra mobile 17.04.0-ce onora solo NO_PROXY.