Respuestas:
No hay una autoridad central que asigne un significado oficial a las variables de entorno antes de que las aplicaciones puedan usarlas. POSIX define el significado de algunas variables ( PATH, TERM, ...) y las listas de varios más en una forma no normativa por ser de uso común, todos ellos en mayúsculas. http_proxyy amigos no es uno de ellos.
A diferencia de todas las variables de entorno básicamente convencionales utilizados por muchas aplicaciones, http_proxy, https_proxy, ftp_proxyy no_proxyson comúnmente minúsculas. No recuerdo ningún programa que solo los entienda en mayúsculas, ni siquiera puedo encontrar uno que los pruebe en mayúsculas. Muchos programas usan solo la variante en minúsculas, incluyendo lynx, wget, curl, perl LWP, perl WWW :: Search, python urllib / urllib2, etc. Entonces, para estas variables, la forma correcta es la minúscula.
El nombre en minúscula se remonta al menos a CERN libwww 2.15 en marzo de 1994 (gracias a Stéphane Chazelas por localizarlo). No sé qué motivó la elección de minúsculas, lo que habría sido inusual incluso entonces.
HTTPS_PROXY. Docker también usa la variante en mayúsculas.
sudo -E apt-add-repository ppa:xxxxx/xxxx. tuve que unset https_proxyyexport HTTPS_PROXY=http://a.b.c.d:xxxx
No existe un estándar y se utilizan versiones en mayúsculas y minúsculas según la aplicación (consulte también HTTPS_PROXY, ALL_PROXY, NO_PROXY).
Por ejemplo:
rizo
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
git
http.proxy
Override the HTTP proxy, normally configured using the http_proxy, https_proxy,
and all_proxy environment variables (see curl(1)). [..]
Pitón
urllib.request.getproxies() admite variantes en minúsculas y mayúsculas.
También menciona un problema de seguridad:
Si se establece la variable de entorno REQUEST_METHOD, que generalmente indica que su script se está ejecutando en un entorno CGI, la variable de entorno HTTP_PROXY (mayúscula _PROXY) se ignorará. Esto se debe a que un cliente puede inyectar esa variable utilizando el encabezado HTTP "Proxy:". Si necesita usar un proxy HTTP en un entorno CGI, use ProxyHandler explícitamente o asegúrese de que el nombre de la variable esté en minúsculas (o al menos el sufijo _proxy).
Algunas aplicaciones permiten NO_PROXYcontener estrellas / rangos de ip, mientras que otras no.
Asi que
export https_proxy=$http_proxy HTTP_PROXY=$http_proxy HTTPS_PROXY=$http_proxy NO_PROXY=$no_proxy
debería haberte cubierto.
La convención es usar todas las variables de entorno de capps al exportarlas, de modo que cuando escriba scripts de shell pueda usar nombres de variables en minúsculas sin preocuparse por las colisiones de nombres con otros programas. Por supuesto, esto es solo una convención, no hay restricción técnica para limitar los nombres de las variables de entorno, por lo que la versión en minúsculas podría usarse en algunos casos, pero la mejor práctica es mayúscula, y recuerde que distinguen entre mayúsculas y minúsculas para que puedan tener diferentes valores.
http_proxyy sus hermanos suelen estar en minúsculas.
http_proxyy amigos debe escribirse en minúsculas, en violación de una convención. El uso de una aplicación HTTP_PROXYsería un error porque sería incompatible con el resto del mundo.
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-> Para el registro, me acabo de enterar de que Docker 17.04.0-ce solo rinde homenaje a NO_PROXY.