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

[Vlad Harchev]

On Sun, 9 Jul 2000, Klaus Weide wrote:

> On Sat, 8 Jul 2000, Vlad Harchev wrote:
> > On Fri, 7 Jul 2000, Klaus Weide wrote:
> > > Executive summary:
> > > I. The approach of using lynxexec/lynxprog is not appropriate for
> > >    general use (unless lynxexec/lynxprog were heavily revised).
> > > II. Some concrete problems with the implementation are discussed.
> > > III. Using lynxcgi instead of lynxexec/lynxprog should be examined.
> > > IV. I suggest to go back to the previous, EXTERNAL-based approach
> > >    and possibly extend that.
> > > 
> > 
> >  My executive summary:
> > 0. Klaus is probably right - lynx{prog,exec}: are too unreliable.
> > I. CERN based approach should not be used as primary mean for mailto:
> >   handling, special support for mailto: URLs that will allow passing 
> > subject, 
> >   cc, to, other fields, and quoted original should be implemented.
> > II. Introduction to muttzilla - an existing wrapper for mailto: and news: 
> > urls
> >   for Netscape can be used with lynx (more correctly - the scripts that are
> >   supplied with it.
> > III. Extending EXTERBAL command is not a wise thing IMO too.
> 
> 
> > > Or maybe those were advantages.  They allowed a way to acces the builtin
> > > normal ACTIVATE-action, in spite of EXTERNAL handlers.
> > 
> >   I don't think they are advantages.
> 
> So we disagree on what is more desirable.  What now? :)

  We can leave the code as is (i.e. with EXTERN_OR_ACTIVATE patch) - I don't
mind this (since I won't use it). But I expect complains from users stating
that 'G' then 'enter' is not equal to 'enter'.
 
> > > Anyway, think what happens if the mailto-UTL contains some special shell
> > > characters.  For example,"mailto:address@hidden;subject=Re:%20somethingw";.
> > > Or is that '&' instead of '&'? - anyway, you have to be prepared for both,
> > > or anything else whether allowed by mailto URL RFCs or not.
> > 
> >   Yes, all %xx should be expanded by something (I assumed that script will 
> > do
> > this). As for special shell characters - I wonder why lynx{prog,exec} don't
> > quote them using backslashes (i.e. why quotiong them is not implemented) - 
> > the
> 
> Because these schemes were meant to act on URL carefully c
> by whoever set up the containing pages, in a local dialup / BBS-like setting.
> There is no provision for variable parts in those schemes.  "Redirecting"
> to those schemes via RULEs provides for that, but is contrary to how
> lynxexec/lynxprog were meant to be used.
> 
> > only reason could be shell portability issues (or direct 'execve' approach
> > that solves all problems could be used - why it's not used already?).
> 
> It wouldn't be the same lynxexec/lynxprog scheme any more.  It is part of the
> lynxexec "protocol" specification that the command is a shell command.  If
> you want something different, then that would be a different kind of URL.
> Maybe you want to suggest a "lynxexec-via-direct-execve:" scheme.  Well,
> something still has to parse a string into argv[] compontents - you'd just
> shift the responsibility for that from system() and "/bin/sh" somewhere else,
> presumably some function in lynx.  Split on every whitespace character?  To
> be generally useful, you probably want to recognize vari us kinds of
> quoteso(<"> and "'").  Soon it starts looking like re-implementing /bin/sh.
> 
> To be fair, you could (and would) still omit anything like ';', '>', '|', '&'
> (in their usual shell meaning), so you would still have a safer mechanism.
> But are you ging to go to that kind of effort anyway?

  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()). It's safe to switch to this approach right
now, since (I guess) lynx{prog,exec} are mostly used on normal URLs

  But from the other POV, all special characters can be used only in mailto:
URLs, and since it looks like we (may be me) are going to implement special
support from mailto: URLs, 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.

> 
> > > II. Now, some comments on the implementation.  I think it's still a good
> > > idea to make "mailto" redirectable or, more generally, subject to 
> > > cernrules
> > > handling; if only for advanced users who are aware of the dangers.
> > > But it should be done differently from Vlad's patch.
> > 
> >  I don't mind this since I didn't spent much time exploring CERN rules
> > implementation.
> 
> > > That's the result of trying to handle redirection from mailto as a
> > > special case in getfile(), rather than using the generic mechanism
> > > that is already in HTLoadDocument()/HTLoad().  You are reinventing the
> > > wheel (or rather: you copy the design from somewhere else, but forget
> > > some important aspects, for example that it has to be round...).
> > 
> >   Yes, since it solved problem I was trying to solve I stopped polishing 
> > it. :)
> 
> You had redefined the problem anyway to be something quite different from
> what Eduardo Chappa wanted.  For him, everything was "working great!"
> after your first patch.

  Probably Eduardo haven't noticed that 'E' 'g' and 'G' and 'x' don't work
with that patch by the time of his post (but these commands execpt 'E' don't
make sense with mailto: URLs).

> 
> > > form getfile(), and calls reply_by_mail().  See code appended to this
> > > message.
> > 
> >   Could you please do it yourself then? I don't know anything about 
> > functions
> > you've mentioned yet, while you know it perfectly and it will take 20 
> > minutes
> > for writing and testing the code you are talking about. I just don't want to
> > spent 2 days on something (and do it possibly with errors) that you can do 
> > so
> > fast.
> 
> Already did it, but can't submit patch immediately, it's mixed in with

 Thanks for this - you've saved a lot of my time so I can spend it on
hacking other free software :)

> other changes that need sorting out.  I was jsut offering you a chance
> to get the change into the devel code more quickly by following my recipe,
> if that's what you are interested in.

  Yes, I don't need this code ASAP so let's wait to your version (I' happily
using CERN rules to redirect ftp: to 'links', and I don't need
cernrules support for mailto: right now).
 
> > > III. Lynxcgi scripts are generally "safer" than execution links (lynxexec/
> 
> >  There will be problems using lyxncgi on DOS and Windows since there is very
> > few environmental space there (and probably Macs - do they ever have
> > environemnt variables?). But direct execution of some program (using
> > lynx{exec,prog} or using special means) won't cause so much problems. So I
> > don't like lynxcgi approach.
> 
> It's still the best combination of flexibility and protection for execution
> of variable commands, where it *is* available without those problems.

  Anyway, mailto: specific handler will be even better than that even on
unixes.
 
> 
> > > So I recommend to go back to the first-attempt patch and try to improve
> > > that.  I don't personally see the need for this "Enter does wild things"
> > > kind of behavior, but if someone wants it, I would prefer to see an
> > > implementation that is based on you first attempt, rather than dangerous
> > > lynxexec stuff.
> > 
> >  I don't think that 1st patch was wise thing so I don't care about it (and 
> > I 
> > think it's better to trash 1st patch).
> 
> You provide no reason here...  Anyway, that patch now *is* in the last
> devel code set, and I thing we agree that the only currently available
> replacement (see subject line) is worse.

  Yes, the only currently available replacement is very dangerous. As for 1st
patch - I don't hurry to trash it but I dislike it very much (since it only
works for ACTIVATE). I don't mind if it will stay forever in the lynx source
tree.

> >  As for hadnling mailto: URLs - it seems that special support for handling
> > them by external programs should be provided. I think that _lynx_ should 
> > parse
> > mailto: URL into subject and etc (or generate necessary subject from the 
> > URL),
> > also it should save the quoted document to the file and pass the filename to
> > the wrapper (of course if external handling of mailto: urls is selected).
> >  There already exists a set of wrapper scripts that were originally meant to
> > be used as handlers for mailto: and news: URLs in netscape - of muttzilla
> > package. Some version (included with current FreeBSD) can be found at
> >    http://www3.bc.sympatico.ca/brian_winters/mutt/muttzilla-0.40.tar.gz 
> > or ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/muttzilla-0.40.tar.gz
> > It contains wrappers for VM,dtmail,mutt and pine - they are shell scripts
> > that treat their arguments as follows:
> >    1  to
> >    2  cc
> >    3  bcc
> >    4  subject
> >    5  (quoted?) body filename
> >    6  org
> 
> I have written in the past, or at least meant to write :), that a major
> problem with all the "let lynx use an external program for mail" ideas
> is the lack of a well-defined interface.  The only well-established
> interface for sending mail is the lower-level "sendmail" command,
> which can be counted on to exist on nearly all UNIX systems, at least,
> and understand the same basic flags.  (Whether the actual implementation
> is "sendmail" or "qmail" or whatever, they all provide the "sendmail"
> interface).  There is no comparable interface for invoking a higher-lever
> mail composer.  You are suggesting one interface now.  Well, that's better
> than nothing, maybe it makes sense to pick this one and require it, maybe
> not.

  I see no disadvantages of picking this interface (and these wrappers). Since
they are shell scripts, the number of actual arguments they accept could be
made infinite using environment variables.
 
> Another problem is that we haven't even defined what we are talking about.
> There are many ways in which lynx can be made to send mail (already, with
> its built-in code).  Try to come up with a list as an exercise, it should
> have at least 5 or 6 entries... only one of which is "following a link to
> a mailto: URL".

  Does it really matter? I think we don't have a lot to borrow from them,
execpt some mailto: URL parsing code and code that generates subject line.

>    Klaus
> 

P.S.: It's funny to see that we spent more than an hour replying to the mails
of each other.
 
> ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden
> 

 Best regards,
  -Vlad


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