Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs

[Vlad Harchev]

On Thu, 13 Jul 2000, Klaus Weide wrote:

> On Thu, 13 Jul 2000, Vlad Harchev wrote:
> > On Wed, 12 Jul 2000, Klaus Weide wrote:
> > > On Mon, 10 Jul 2000, Vlad Harchev wrote:
> > > >   I already told you that quoting every special character with 
> > > > backslash in
> > > > the URL will work very reliably (I even think it will be the most 
> > > > reliable way
> > > > beside reimplementing systenm()).
> > > 
> > > We already have HTQuoteParameter() for UNIX shells, why do you think a
> > > > there won't be need for using lynx{prog,exec} with
> > > > them, so there is no actual need for all this quoting stuff and for 
> > > > allowing
> > > > mailto: to be handled by CERN rules.
> 
> Still nice to allow it for those who choose to and accept the limitations
> (like it works anly on really simple mailto addresses without special
> characters, and it can be dangerous).

  I don't think that this should have one of the topmost priorities since it's
not that useful then.
 
> > > > But anyway, the '*' in "Map blah lynx{prog,exec}://foo *" could be 
> > > > substituted 
> > > > with quoting special characters applied - this is not difficult, or 
> > > > another 
> > > > behaviour to be introduced, say asterisk inside single quotes '*', that 
> > > > will 
> > > > mean "matching URL part, with shell special characters escaped") ). 
> > > > This will
> > > > allow reliable use of mailto: URLs in cern rules too.
> > > 
> > > Yes, that is where such a change would belong, not in the interpretation
> > > of lynxexec URLs themselves.  Currently the * means just literal 
> > > replacement.
> > > You can't just change that either; you'd have to invent some new kind of
> > > syntax or something like a "MapAndEscape" rule.
> > 
> >  This is what I as talking about in the paragraph above - I was talking 
> > about
> > introducing special meaning for "asterisk in single quotes" (not changing 
> > the
> > semantics associated with "asterisk") - it could mean "the string that 
> > matched
> > * but escaped for safe passing as single argument for some command via 
> > shell".
> 
> Well it _does_ change the meaning of asterisk, as well as the meaning of
> single quote characters.  In a way that is only useful for lynx{exec,prog}
> but not useful for other URL schemes.

> Thinking more "generic" (as you advocate :) ), the following would be
> more generally useful:
> 
> #Transform  URL1  URL2  WHICH_CHARS  HOW  WHAT
> #  Like  Map URL1 URL2 , but additionally tranforming hte URL in some way.
> #  WHICH_CHARS is one of "unsafeshellchars", "urlunsafechars", "urlreserved" 
> ...
> #  HOW is "tosafeshellstring", "urlencode", "urldecode", ...
> #  WHAT is "all" (transform whole URL2 after replacing *) or
> #          "match" (transform only the characters matched by *)
> # For example,
> #   http://some.site/*  ->  http://localhost/cgi-bin/handler?url=*
> #   would use something like  urlreserved urlencode match, and
> #   http://site.that.unnecessarily.redirects/blah?url=http%3A*  ->  http:*
> #   would use  urlreserved urldecode match.
> 
> Wanna do it? :)

 Well, I would like not to do this. At least unlikely in the next 2 weeks.

> Actually, RULEs could be much more useful if it had a more general
> matching mechanism.  Just one '*' is very limiting.  It should have
> the full power of apache's mod_rewrite, with regular expressions etc...

  Yes, it's more generic :)
  Yes, it would be nice to have them. But even without regexs, I think it
would be nice to hack them into Mozilla too.

> Or maybe not.  The reason the mechanism exists at all now is because
> the basic code was there anyway (but unused), so I resurrected it
> and added some extensions that were useful and didn't require big
> changes.  So it's basically limited to what the original CERN libwww
> code easily allowed.
>
>    Klaus
> 
> 
> ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden
> 

 Best regards,
  -Vlad


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden