Re: lynx-dev Re: STARTFILE patch

[Klaus Weide]

On Wed, 14 Apr 1999, Philip Webb wrote:

> 990413 KW commented on my update of STARTFILE info in  lynx.cfg : 
> >> # STARTFILE is the default starting URL if none is specified
> >> #   on the command line or via a WWW_HOME environment variable;
> >> #   Lynx will refuse to start without a starting URL of some kind.
> >> # STARTFILE can be remote, e.g. http://www.w3.org/default.html ,
> >> #                or local, e.g. file://localhost/PATH_TO/FILENAME ,
> >> #           where PATH_TO is replaced with the complete path to FILENAME
> >> #           using Unix shell syntax and including the device on VMS.
> >> # The default offered for ordinary users is their current directory:
> >> STARTFILE:.
> > This change flies in the face of what the documentation says,
> > including the comments just above it.
> 
> so the documentation needs further improvement: your turn ...
>
> > "." is not a URL!  More generally, there are quite a few places
> >   - in userdefs.h
> >   - in lynx.cfg
> >   - in ynx_url_support.html
> > that say that something "must" be a URL.
> > !! URLs are not filenames.  Filenames are not URLs. !!
> > a local file URL is not just a filename prefixed with "file://localhost".
> > a local filename is not just a file: URL stripped of "file://localhost".
> > That happens to be true only sometimes, and then only for some OSs.
> 
> in the absence of a proper account of exceptions,
> i would maintain that in the context of everyday browsing,
> a local file URL is a filename prefixed with  file://localhost

In the context of *your* everyday browsing, maybe.  Certainly not in
any Windows user's (or VMS user's, or OS/2 user's, etc.).
And not if you happen to have a habit to use certain characters in
filenames.

> & a local filename may be used as a practical abbreviation
> for a complete local file URL which includes  file://localhost ;
>  .  is then a double abbreviation for a local file URL.
>
> i may also have views about angels & pins, but that's off topic.

If that's supposed to mean that the difference between URLs and filenames
is all too academic: no it isn't.  You can brush it away with some
some 'It's basically the same' attitude, but that only increases the
confusion.

> the following discussion seems related solely to documentation:
>
> > Some of the "must"s are not technically required.
> > [snip]
> > Putting 'note: STARTFILE must be a URL' directly followed
> > by '#define STARTFILE "."' in  userdefs.h  just increases the confusion.
>                                  ^^^^^^^^^^ lynx.cfg ?

I did mean userdefs.h here, note the '#define'.  It's like that in dev.22
now.

> > To *decrease* the confusion, it should be stated clearly what is what:
> >[ snip ]
> 
> this seems to contain lots of sense: i look forward to your patches.
>  
> > The patch (without doc changes) increases the discrepancy
> > between documentation and reality,
> 
> ditto
> 
> > but I also question its usefulness.  Is it a good thing
> > to start with browsing the *current* directory by default?
> 
> on further thought, i agree with LP: best default is Main Help Page.
> can TD change that by hand for dev.23 ?
> 
> > I guess Philip got tired of seeing all the problems people are having
> > with lynx refusing to start,
> 
> yes, of course.
> 
> > but in most cases this change just hides or defers the problem.
> > In most cases (I assume) people *want* to make a network connection.
> > So now they'll see Lynx start up and not exit immediately,
> > but if there network is somehow misconfigured they still can't go anywhere;
> > and if the problem is just that they haven't configured lynx
> > (when they would want to), it also doesn't help much.
> 
> no: you haven't been following users' inquiries closely enough.

I have at least seen most of them.  Your description (below) only
talks about a subset of them.

> the problem arises when l.b.o. is down -- not infrequently -- ,
> so that Lynx refuses to start & the user can't even enter  h ;
> this could happen with any remote site,
> so the solution has to be to make the default a local URL:
> it has to be one we know will always be available,

That's only the solution if you define the problem in a certain way.
But different people have different problems.

0) When users have problems like "lynx: Can't access start file
file://localhost/afs/uni-bonn.de/home/uzr109/lynx/htmls/home_voe.html"
(as in one recent report), then obviously this has nothing to do with
l.b.o, but is just plain misconfiguration.  Changing the distribution
default would obviously not help here, since the default isn't being
used.

1) When l.b.o is down or unreachable, and the user *wants to* go to l.b.o,
then the problem is that l.b.o is down or unreachable.

2) When l.b.o is down or unreachable, and the user doesn't want to go to
l.b.o but rather just start up lynx in order to go somewhere, then the
problem is that (a) lynx has not been properly configured (to a more
appropriate place) and/or (b) the user hasn't learned how to invoke
lynx to go to the desired place directly.

3) When l.b.o is unreachable as well as any other remote site because
networking or DNS doesn't work, then the problem is the network or
DNS setup.

The preferred solution would be
 - for 1), to improve stability and reachability of lynx.browser.org
   (or ultimately, point the DNS name to a different box).
 - for 2), system admins / users should configure lynx.  Users should
   learn to point lynx the right way.
   Maybe some documentation changes would help, but there's always people
   who don't read any docs.
 - for 3), the underlying network problem has to be fixed.  This seems
   to be a problem mostly for users of 386 binaries.  Maybe creators of
   those packages can make further improvements (or maybe they are already
   doing everything that makes sense).

I see only two possibilities where a default of 'STARTFILE:.' would solve
the problem (rather than just shifting it):

4) The user wants to just test whether lynx "works", probably after having
just installed it.  User is mislead into thinking "lynx is broken" when
it's really l.b.o something else.
 - Well, the problem is "solved" with 'STARTFILE:.', the user now thinks
   he has no problem when in reality he does.

5) You regard the amount of mail to lynx-dev with 'Can't access start file'
as the real problem.  Maybe for some reaon you feel obliged to answer every
single one of them, and want to decrease your self-imposed workload.
-  Well, you could indeed decrease the number of mails who say 'Can't access
   start file'.  Instead all the folks who would have sent them will send
   error reports with different symptoms (minus the few who neever browse
   remote documents anyway).  Unless you somehow come up with a way that
   lynx can detect and analyze which is the real underlying problem and
   then tell the user how to solve it without writing to lynx-dev.
Better solution, if 5) should apply: take a break.  :)

> which makes the Main Help Page the best choice,
> as there may be systems which won't understand  . ,

That would be a bug that has to be fixed

> but given such a default, we can be confident they can at least get started.

To get lynx started up isn't much of an improvement, unless it works
right after that.  I.e. of 0) - 3) above, this works only for case 2),
which A) doesn't seem to be the most frequent nowadays, and B) those
users shouldn't have been going to the unchanged installation default
all the time anyway, and C) (unless anonymous/menu installation) users
can easily type 'lynx .' or 'lynx -book' or 'lynx <my-url>' (and D) 
if this happens for anonymous/menu things are beyonf hope anyway).
There's no guarantee that a local copy of the Main Help Page is
available at runtime where lynx expects it.  My guess is that the
number of installations where this is broken outweighs the l.b.o
downtime/reachability and startfile-unconfigured problems combined.

> typically, queries come from people using a shared Lynx,
> whose invariably overworked sysadmin hasn't changed the default.

Seems to me that more recently most 'Can't access start file' problems
were coming from users of the DOS and Windows ports.

> > Anyway, I suggest it would be better to at least start with
> > the user's home directory by default, instead of '.'.
> > this can be specified in URL form: "file://localhost/~/" should work.
> 
> that's another possibility, but Main Help Page seems better.
>  
> >> # *** NBB *** System administrators with ANONYMOUS USERS !!!
> >> #   set STARTFILE to a REMOTE FILE by uncommenting the next line:
> >> #STARTFILE:http://lynx.browser.org/
> >> #   and commenting out the default offered above;
> >> #   you may, of course, choose to replace `lynx.browser.org'
> >> #   with another remote/local file which you know to be safe.
> > It doesn't make much sense to ask system administrators
> > with ANONYMOUS USERS (them and only them) to set STARTFILE
> > to "http://lynx.browser.org/"; or to a 'REMOTE FILE'.
> > Those are probably exactly the folks who want to point STARTFILE
> > to a specific (probably local) location.  Not just 'you may', they SHOULD.
> 
> well yes, but we don't know which local location, do we?

No, and why should we?  People configuring for use by anonymous users
have to go through the files carefully anyway and put in whatever fits
their situation.   No point in starting to shout at them in this one
place as if this was all they have to do.

> and we have to have a very simple default they can substitute
> or we'll have Henry (grin) screaming that the sky is falling.
> by all means, add  1 - 2 lines  of further advice: your patch?
>
> > OTOH it looks now as if http://lynx.browser.org/ were only suggested
> > for those administrators with ANONYMOUS USERS, not for others.
> > It should be suggested as an alternative for everyone.
> > Even better, it should be more strongly suggested
> > that folks actually change STARTFILE to *what they want*.
> 
> as i said: your patch?

My preliminary patch would consist of completely removing that whole
*** NBB *** paragraph, as Henry suggested.  (What's NBB supposed to mean
anyway?)

> >> #   Lynx will refuse to start without a starting URL of some kind.
> > It isn't actually possible to *not* have a starting URL of some kind.
> > There's the userdefs.h default, lynx can't even be compiled without it
> > (as you have noticed); so this doesn't make sense.
>  
> `Lynx will refuse to start if it cannot find a starting URL of some kind':
> your patch?

You submit a patch, its gets included.  Problems and inconsistencies
are pointed out.  You are reacting as if it were none of your business -
let others fix problems you created, right?

I already have a queue of other patches I haven't gotten around to
brush up and send.  Maybe I'll eventually send some changes for this
stuff, but I'd prefer someone else to do it, before I get to it.
The use of '.'  *as a potential,optional value* could be more prominently
suggested.  Maybe you can find it in your heart...

That would be for clarifying documentation.  Leonid seems to be
interested in unifying option handling for filenames, which could
be related.  Until such changes happen, I suggest that the startfile
default change back to "http://lynx.browser.org/";.

I am not absolutely opposed to changing it so something local
(but at mentioned it should probably not be ".".)  It just seems
to me it's not such a good idea.

What's "http://lynx.browser.org/";, really?  It is just a pointer
that can be changed at any time (by editiong the page, or by
changing the pointer by

    $ nslookup -q=SOA browser.org
    ...
    browser.org
        origin = ns0.plig.net
        mail addr = hostmaster.browser.org  [presumably Rob Partington])

to point to the most sensible "default" page.  The whole point of
the page is to serve that purpose.  As soon as we try to hardwire
more help or error text into lynx, there is the danger that it will be
outdated soon.  If additional help or error text is distributed as
local files to-be-install, there's also the same danger execpt for
users/sites which keep updating the files, and the separate files
may get "lost" anyway.


   Klaus