[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
Re: lynx-dev "gettidy.sh": why must one define proxy before evoking Lynx?
Sat, 14 Aug 1999 19:27:47 -0400 (EDT)
990812 Klaus Weide replied to Henry Nelson:
>> 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
> The recognized ones can be found by looking for '_proxy' in LYReadCFG.c.
this simply repeats the description: it's not an explanation.
> 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:'.
it would seem therefore that Lynx can handle arbitrary foo_proxy's ...
> the lynx.cfg handling code works by putting those options
> (from the fixed set) into the environment.
... but for some -- still unexplained -- reason, lynx.cfg is restricted.
this looks like another left-over from the Age of Giants,
whose rationale is lost in the mists of history by now
& which should quite possibly be updated.
i'm a spectator here, as i don't use proxies,
but HN may still have a problem which has a small programming solution.
SUPPORT ___________//___, Philip Webb : address@hidden
ELECTRIC /]     | Centre for Urban & Community Studies
TRANSIT `-O----------O---' University of Toronto