lynx-dev
[Top][All Lists]
Advanced

[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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]