Re: lynx-dev lynxcgi and lynxexec problems

[Klaus Weide]

On Mon, 9 Aug 1999, Paul Slootman wrote:
> On Sun 08 Aug 1999, Philip Webb wrote:
> > this seems to be a piece of Lynx which dates back to the Age of Giants
> > & which has been neglected since then & never properly documented.
> 
> It's a pity, I think, because everyone I mentioned lynxexec to had never
> heard of it and agreed that it was a cool feature.

Some reasons against advertizing it much:
1. It makes for browser-specific HTML, something lynx has to struggle with
   in other areas (NS-HTML, MS-HTML).
2. The possibility to run programs controlled by markup is
   potentially dangerous, witness all the exploits that have been
   published for other browsers.  Of course that's why there are all those
   options to restrict use, but probably nobody here is willing to state
   with confidence that there are no holes in them.  (I am not saying
   there are holes, but nobody has audited the code for that kind of thing
   afaik, and the folks who likely would have the greatest interest in
   doing that - freenet-type setups where "lynxexec:" would be used
   extensively for many users - don't contribute much on the list.)
3. The syntax is weird - generally, spaces, tabs and other special and
   restricted characters should be %-escaped in URLs and unescaped before
   use.  The code handling lynxexec: and lynxprog: unescapes some 
   %-encoded characters but not others, and it occurs at a different level
   than for other URLs, so it's all a bit inconsistent.
Of course that doesn't mean you shouldn't use the feature where you feel
it is appropriate, I just thought I should mention these points.

Now "lynxcgi", that's something I find much cooler...


> > while any attempt by others to improve documentation
> > tends to be greeted rather like a new translation of the Bible.
> 
> Hmm, that's unfortunate. Most other projects welcome any offers of
> improved docs with open arms (I've written sizeable chunks for
> ISDN4linux).

That was just one person's opinion / experience, don't take it as "Gospel"
(since we are drifting into these kinds of metaphors...)

> I'll wait until I've played around with lynx a bit more (and have a
> better felling for it ) before offering to contribute any docs,
> though...

Since you want to play around with this, some more things you may be
interested in:

The message you mention in your Debian bug report (containing "See the
Options menu (use O)") requires compilation in a special way to make
sense.  (IOW, we should change the code to not show it when it isn't
appropriate.)  Up to (and including) released 2.8.2, the macro
ALLOW_USERS_TO_CHANGE_EXEC_WITHIN_OPTIONS had to be defined in userdefs.h.
In most recent 2.8.3dev.N code, this has been replaced by the shorter
ENABLE_OPTS_CHANGE_EXEC and can also by set with './configure
--enable-change-exec'.  If compiled with the macro defined, an addition
choice should appear on the 'O' screen/page for "Execution links".

I see now that there is another bug, wrt. handling of ""Execution links"
on the forms 'O'ptions page: lynx ignores -restrictions=exec_frozen,
which should disable this choice at runtime (it is part of the generic
"default" restrictions set with -anonymous).  This works with the old
style 'O'ptions screen, -forms_options=off.  (tested: 2.8.3dev.4)

For an arcane discussion of one use of "lynxexec:" you may want to
read samples/cernrules.txt from the 2.8.3dev.N code, in particular the
section "9. Invent your own scheme".  Note this file isn't in the
Debian package at all (although referred to by lynx.cfg), but the
discussion there only applies to features added after 2.8.2 anyway.
I wrote that text - wonder whether it makes sense to anyone...

    Klaus