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

[Vlad Harchev]

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
> different implementation that quotes in a different way (and probably
> produces less readable strings) but otherwise has the same purpose
> (pass a string to a shell command) is desirable?

  I was unaware of this function - it works even better than escaping with
slash - I have an impression that encoding HTQuoteParameter performs will be
correctly interpreted even by the broken dos shell.
 
> > It's safe to switch to this approach right
> > now, since (I guess) lynx{prog,exec} are mostly used on normal URLs
> 
> It's never "safe to switch" based on "I guess" and "mostly"!

> It appears you want to redefine what the [rest] in lynxexec:[rest] means.
> Before: [rest] is a string that is passed to system() as-is.  (Well, except
>         for some processing of the string that lynx does, like space 
> collapsing,
>       '%20'-decoding, '//', '/'-at-end munging...)
> After: [rest] is a string in which some characters are further escaped or
>        quoted, so lynx has to do some de-quoting before invoking the command;
> Or (After version 2): [rest] is a string to which lynx will apply further
>        quoting of some characters before invoking the command.
> 
> Either way, you are redefining the meaning, so you are breaking some people's
> existing links.  Lynxexec URLs were never meant to be created on the fly by
> transforming some other URLs to them.  You can't just redefine their meaning
> because that would be convenient for that purpose (an afterthought).

 Yes, you are right - lynx{exec,prog} were never meant to be created on the
fly by transforming some other URLs to them, so no need to tweak them.
 
> >   But from the other POV, all special characters can be used only in mailto:
> > URLs,
> 
> I don't understand what you are trying to say here.

  Please ignore it.

> > and since it looks like we (may be me) are going to implement special
> > support from mailto: URLs,
> 
> Still undefined what "special support from mailto: URLs" means and when
> it is supposed to apply.

 It would be invoked (if enabled) on activation of mailto: links and (probably
on sending comments using 'c').

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

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

 Best regards,
  -Vlad


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