proxy syntax in elinks

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============1622002244174605100==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="Fe0J3eOlW8EdefxrN3rQ1K4TH5vg0SbTN"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Fe0J3eOlW8EdefxrN3rQ1K4TH5vg0SbTN
Content-Type: multipart/mixed; boundary="NATk4Cews5j1k4eWNt5BDvfMoeFq4birW";
 protected-headers="v1"
From: Thomas Seeling <[email protected]>
To: [email protected]
Message-ID: <[email protected]>
Subject: proxy syntax in elinks

--NATk4Cews5j1k4eWNt5BDvfMoeFq4birW
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hallo,


I apologize if this question has been asked already, I found elinks as a
very convenient tool only just recently.
I'm behind firewalls and proxies most of the time so I have to set proxy
definitions.

The common procedure is to set http_proxy etc. with a particular syntax
(note variable names in lowercase), as was established 20+ years ago
with the first cern libwww releases ("I was there at the dawn of the 3rd
age of mankind", sorry, just had to quote this).

What stymies me is why elinks establishes different variable names and
even invented a new syntax for the proxy definition, and it hunts me
every time when I run scripts that I have to maintain 2 different sets
of proxy definitions in a config file.

Why does elinks not honor the usual http_proxy variable, and insist on
using HTTP_PROXY with host:port syntax?

Tschau...Thomas
--=20
"Do you wanna be a legend or a passing footprint on the sands of time?"


--NATk4Cews5j1k4eWNt5BDvfMoeFq4birW--

--Fe0J3eOlW8EdefxrN3rQ1K4TH5vg0SbTN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iQEcBAEBAgAGBQJYNbTOAAoJEJx3bdG4OOtN83MH/1jfg02n+c6mnR6rZjDPofun
d0fO0vbZzg7S5jvr1RY7wbY0L+8QvmRLrcvzsG5e7GWwm8KWzpGCvNrJlVFdWuRF
gEAs6SzZEzYFZv+Xkw4uR8ng2lV9gXlyEb2c1hxUsar+Rjh70++5lKW0BiCm1+k7
ZXApuuc4Vy9lSOXET7bPdRJmk38xieelXOqdg8VDL41pCffg3zDf1cXuyCacRYwq
uJZbctOV5NOu7YeA1i3a6aRv/WWyCTKBbSAvnfj2KmKbsU0sqiYuoNKPMUWIliQA
4q28xzxenDOd+8QYovaJQlCbn/ap5otVNStBkmCxPzXNqQl/5XPcSefAeXV8M7M=
=am9d
-----END PGP SIGNATURE-----

--Fe0J3eOlW8EdefxrN3rQ1K4TH5vg0SbTN--

--===============1622002244174605100==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

LS0gCmh0dHA6Ly9saXN0cy5saW51eGZyb21zY3JhdGNoLm9yZy9saXN0aW5mby9lbGlua3MtdXNl
cnMKVW5zdWJzY3JpYmU6IFNlZSB0aGUgYWJvdmUgaW5mb3JtYXRpb24gcGFnZQo=

--===============1622002244174605100==--