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

[Klaus Weide]

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? :)

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


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


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

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


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

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

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

   Klaus


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