[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
- lynx-dev STARTFILE bug?, Philip Webb, 1999/04/01
- Re: STARTFILE bug? [lynx-dev], Michael Warner, 1999/04/01
- Re: STARTFILE bug? [lynx-dev], Philip Webb, 1999/04/02
- Re: STARTFILE bug? [lynx-dev], Greg Marr, 1999/04/02
- lynx-dev Re: STARTFILE patch, Philip Webb, 1999/04/02
- Re: lynx-dev Re: STARTFILE patch, Klaus Weide, 1999/04/13
- Re: lynx-dev Re: STARTFILE patch, Leonid Pauzner, 1999/04/13
- Re: lynx-dev Re: STARTFILE patch,
Philip Webb <=
- Re: lynx-dev Re: STARTFILE patch, Klaus Weide, 1999/04/14
- Re: lynx-dev Re: STARTFILE patch, Webmaster Jim, 1999/04/14
- Re: lynx-dev Re: STARTFILE patch, Doug Kaufman, 1999/04/15
- Re: lynx-dev Re: STARTFILE patch, Klaus Weide, 1999/04/16
- Re: STARTFILE bug? [lynx-dev], Doug Kaufman, 1999/04/02