[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev "gettidy.sh": why must one define proxy before evoking Lynx
From: |
Klaus Weide |
Subject: |
Re: lynx-dev "gettidy.sh": why must one define proxy before evoking Lynx? |
Date: |
Thu, 12 Aug 1999 01:17:36 -0500 (CDT) |
On Thu, 12 Aug 1999, Henry Nelson wrote:
> Before your keyboard shorts out, can you explain in layman's terms
> the reason why defining the proxies in lynx.cfg will not work?
>
> # o Define the following environment variables *outside of lynx*,
> # before starting lynx. Putting them in lynx.cfg *does not work*.
> # xhttp_proxy='lynxcgi://localhost/PATH/TO/gettidy.sh?/'
> # xxhttp_proxy='lynxcgi://localhost/PATH/TO/gettidy.sh?/'
> # export xhttp_proxy xxhttp_proxy
The function for parsing lynx.cfg recognizes only a fixed set of
hardwirded foo_proxy names, all others are ignored; this isn't different
from other unrecognized lynx.cfg options (which are ignored).
The recognized ones can be found by looking for '_proxy' in LYReadCFG.c.
The code that actually looks for and applies the proxy settings
accesses the environment directly with getenv(), so it can look for
'foo_proxy' for any arbitrary 'foo:'. Actually, the lynx.cfg handling
code works by putting those options (from the fixed set) into the
environment.
Btw. with the cernrules stuff there should now be a less hackish way
to specify the x(x?)http -> lynxcgi translation. It would still require
to set the x(x?)http_proxy env variable to something, though, to make
lynx accept the URL in the first place. And the way I have described
previously (which you quote) should still work, even with -DNO_RULES.
Klaus