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

[Klaus Weide]

On Sat, 14 Aug 1999, Philip Webb wrote:

> 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.

Shrug.  It does not just repeat the description, as anyone can see.
Now if you are not satisfied with this explanation, that's a different
matter...

> > 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.

You haven't explained why you *expect* lynx.cfg to recognize some options
via some form of wildcard matching, when it doesn't do so for any other
options.

> 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.

Nobody has ever _asked for_ recognition of arbitrary *_proxy in lynx.cfg.
It seems all normally used foo_proxy settings are recognized.  The
need for arbitrary_foo just hasn't arisen.  The xhttp_proxy, xxhttp_proxy
etc. are a trick that happens to work (across many lynx versions), nothing
more; it would still be no more than a trick even if recognized in
lynx.cfg.

This has nothing to do with your favorite "Age of Giants" myth or a "lost
rationale".  Wildcard lynx.cfg option matching is not there because
nobody has needed it.  If *_proxy tricks become popular so that people
ask for it, then it could be added (I assume without much difficulty).
So far that hasn't happened.


   Klaus