Re: lynx-dev lynxcgi and lynxexec problems

[Klaus Weide]

On Sat, 7 Aug 1999, Paul Slootman wrote:
> On Fri 06 Aug 1999, Klaus Weide wrote:
> 
> > I happen to have already seen your Debian bug report at
> > <http://www.debian.org/Bugs/db/42/42494.html>.  Unfortunately you don't
> > honor us here with the same level of detail.
> 
> I didn't know whether such a verbose message straight away would be
> appreciated here... Especially if it happened to be something simple.

Oh, more concrete information is always good, and a specific test case
even better - if it it reasonably short and can be transmitted without
resorting to UU- or MIME-encoding, anyway.

> > The first thing you should do is look at the lynx.cfg from the current
> > unstable (dev.N) lynx code.  See <http://sol.slcc.edu/lynx/current/>.
> > If you just want to look at one file, you can find it by going into
> > the "breakout" subdirectory from there, if you don't want to download
> > the source.
> 
> OK, I've had a quick look, and it looks promising. It's too late to say
> for sure though :-)

The major difference I was thinking of is this change (submitted by me)

old:
   # [...] any lynxexec
   # or lynxprog command will be permitted if it was referenced with a URL
                                                     ^^^^^^^^^^^^^^^
   # beginning with that string.
new:
   # [...] any lynxexec
   # or lynxprog command will be permitted if it was referenced from within
                                                     ^^^^^^^^^^^^^^^^^^^^^^
   # a document whose URL begins with that string.

In my understanding "old" always was meant to say what "new" now
(hopefully) expresses.  The "old" formulation had kept me from
understanding the meaning for a long time, too.  I hope with the change
the meaning of the TRUSTED_EXEC string, and why there are two parts
(separated by <tab>), becomes understandabe.

> > Trust me, you want to understand the way lynxexec: etc. are controlled
> > with TRUSTED_EXEC before you build something with it.
> 
> Yes, that's clear. Unfortunately I couldn't really find any clear
> docs (the docs directory in 2.8.2 only contains announces and change
> logs, which is a bit disconcerting when you first look for more
> information).  

If you are talking about the Debian (binary) package - you cannot rely
on all uptream doc files being included (although in this case - about
exec stuff - this is not the problem; but I reported a bug about some
missing sample files).

> I've been using lynx casually for a couple of years, so
> the basics (as far as using it as a web browser is concerned) are clear.
> It's just that when I tried to find more information about lynxexec
> (which I was very happy to see that it exists!), it's very hard to do
> so. What I often do in such cases is 'find -type f | xargs grep -li
> subject' to see where the subject is listed, and then examine those
> files. However, here the result is that it is only really documented in
> the sample config file...

Yes, that's true.  The ultimate 'documentation' of those options
used to be, de facto, the collective wisdom of lynx-dev list...

It is my impression that lynxprog: and lynxexec: are mostly used by
folks using lynx as a menu system in freenet-like setups, and that
the code originally came from those folks.  There aren't many of those
folks left active on this list however.

> Please don't get me wrong, I know how hard it is to write
> documentation! That's why I like exim so much, for example (see
> www.exim.org, everything is explained in much detail).

If you have time to suggest some specific wording changes or additions,
feel welcome to send them.

> > Your example (which you gave in the Debian bug report) should NOT work
> > as given, neither with 2.8.2 nor with 2.8.1.  In fact, I tested it with
> > the Debian 2.8.1-3 and confirmed that it did not work (as expected).
> > You must have done something differently.
> 
> Damn. I just tried it, and you're right. I'm sure I had it working
> somewhere... I'll check back on that.
> However, you didn't report this to the BTS? I could have looked into
> this earlier in that case; I waited a day before sending a message here.

Well, I might have done that later...  It should be the Debian
maintainer's job to first respond, and to check whether a bug is
Debian-specific.  For example I can't really check the behavior of the
lynx_2.8.2-1 package, since I don't run that (no glibc2.1 system here).

But I'm glad you found your way here.  Saves me the "I am not the Debian
maintainer for lynx, but saw your bug report, and..." introductions,
and makes the diescussion avialable to other lynx-dev folks without
additional cc'ing.

> > Basically, it's not supposed to work because "lynxcgi:/tmp/x.cgi" is
> > not recognized as equivalent to "local".  But you can change that (and
> 
> Hmm, it looks pretty local to me :-)  But the concept of "local" is
> probably different in lynx?

The concept of "local" used in this context is specific to this context
only, not just specific to lynx...  I would say "local" is just a fancy
word here (possibly misleading) for "whatever TRUSTED_EXEC says (or
defaults to)".  Yes, it could be made clearer, but I think the information
is there if you read the relevant screenfuls very carefully.

Well that's *my* understanding of the description, verified by a little
testing and a little looking at code, but not guaranteed to be correct.

   Klaus