lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Re: STARTFILE patch


From: Philip Webb
Subject: Re: lynx-dev Re: STARTFILE patch
Date: Wed, 14 Apr 1999 00:57:19 -0400 (EDT)

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

the following discussion seems related solely to documentation:

> Some of the "must"s are not technically required.
> They should probably be replaced by "should"s.
> This applies for everything that Lynx passes through a pair of
>             LYFillLocalFileURL(...);
>             LYEnsureAbsoluteURL(...);  calls:
> at least startfile, homepage, 'g'/'G' URLs.
> which Lynx tries to convert to URLs if they aren't already.
> It's described in  lynx_url_support.html ,
> in the section from "When entering a URL on the command line..."
> to "These expansions are SOLELY for startfile or 'g'oto entries!"
> but "SOLELY" may not be true any more(??).
> Anyway, something like "/home/myname/" or "." is not a URL
> in terms of  lynx_url_support.html , no matter how you slice it.
> Putting 'note: STARTFILE must be a URL' directly followed
> by '#define STARTFILE "."' in  userdefs.h  just increases the confusion.
                                 ^^^^^^^^^^ lynx.cfg ?
> To *decrease* the confusion, it should be stated clearly what is what:
> what kind of object is expected by each  lynx.cfg  option,
>  userdefs.h  #define  etc.  There are at least three kinds of objects:
>  - 'real' (absolute) URLs
>  - the tentative URLs above.
>    Let's give them a name for reference: say U-URL (user URL).
>     lynx_url_support.html  should document what forms are acceptable,
>    in addition to strict 'real' URLs.
>    lynx.cfg, userdefs.h, 'g'oto help should say where a U-URL is allowed.
>  - filenames.  Things that aren't converted to URLs at all.
> This is only a broad classification.
> Some filenames are further treated specially
> (like bookmark files, sometimes they are supposed to start with './'
> where '.' stands for the home dir).
> VMS code defines a 'Unix syntax' even for most (all?) non-URL filenames.
> Windows/DOS code may accept Unix form for some filenames.  And so on...

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.
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,
which makes the Main Help Page the best choice,
as there may be systems which won't understand  . ,
but given such a default, we can be confident they can at least get started.
typically, queries come from people using a shared Lynx,
whose invariably overworked sysadmin hasn't changed the default.
 
> 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?
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?

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

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : address@hidden
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto

reply via email to

[Prev in Thread] Current Thread [Next in Thread]