Re: lynx-dev "gettidy.sh": why must one define proxy before evoking Lynx?

[Philip Webb]

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