lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev 2.8.2rel.1


From: Klaus Weide
Subject: Re: lynx-dev 2.8.2rel.1
Date: Tue, 2 Nov 1999 10:06:03 -0600 (CST)

On Mon, 1 Nov 1999 address@hidden wrote:

> The second involves some new default behavior in 2.8.2 For shared use
> on a large multi-user Solaris 2.6 system I intend to replace 2.8rel.2
> (1998) with 2.8.2rel.1 (01 Jun 1999). I notice that if the new version
> is given a bogus local file or URL without the protocol prefix the
> browser defaults to the local root directory.  While this the
> equivalent of any older version pointed to the root directory, i.e.
> "lynx /", it seems it might encourage the curious to poke around. I
> find no compilation  or runtime configuration options to address this.
> Is this an intentional change? Any suggestions for returning to the old
> default with the new version?

That's a bug.

[ From my not-yet-in-2.8.3dev.13 changes, currently in patch
  upd2.8.3dev.13.diff.gz  at <http://enteract.com/~kweide/lynx/>: ] 
* The 'fixit' change of 1999-05-16 didn't really let LYConvertToURL()
  revert to the right old behavior in the non-'g' use.  Now return a
  file URL for the nonexisting file in the relevant situation again,
  as before 1998-03-25, instead of an erroneous "file://localhost"
  which (on Unix-like systems at least) would result in access to the
  root directory.  This change (like the changes of 1999-05-16 and
  1998-03-25) only matters for strings that aren't already in absolute
  URL form, don't start with a slash (or, for DOSPATH systems, other
  path separator) either, and don't get turned into remote URLs by
  successful 'guessing' and DNS lookup.  None of the changes affect
  VMS.
[ Referenced older CHANGES entries: ]
1999-05-16 (2.8.2pre.4)
* add 'fixit' parameter to LYEnsureAbsoluteURL() to suppress logic in
  LYConvertToURL() that was changed in 2.8.1dev.4, to re-offer the original
  string after an invalid URL is entered at a 'g' prompt.  The calls to support
  'g' are unmodified; other calls revert to the older behavior (recommended by
  KW) -TD
1998-03-25 (2.8.1dev.4)
* restore original string in LYUtils.c when user enters a badly formed or
  nonexistent URL when prompted for Goto/history list (patch by Randall
  <address@hidden>).  Otherwise Lynx would always attempt to load a
  local file if the original string omits scheme:// prefix but guessing fails.

> Example with the bogus file/url jfdfjsl:
> 
> % lynx_2.8rel.2 jfdfjsl
> 
> Alert!: Unable to access document.
> 
> lynx: Can't access startfile file://localhost/src/lynx/lynx2-8-2/jfdfjsl
> ---
> % lynx_2.8.2rel.1 jfdfjsl
> 
>                                                           / directory (p1 of 
> 2)
> 
> Current directory is /

(A corrected version would also try "URL guessing" in that cases, i.e.
DNS lookup for jfdfjsl, www.jfdfjsl.com etc. (dependent on configuration).)

A -trace might be also helpful, look for lines like
   STARTFILE 'jfdfjsl' is not a URL
   Converted 'jfdfjsl' to '/some/path/jfdfjsl'
   Can't stat() or fopen() '/some/path/jfdfjsl'
   Looking up jfdfjsl first.
in the generated ~/Lynx.trace.

Also test the behavior separately from a 'g'oto prompt (not just for a
startfile).

If you want just the two-line fix from my patch backported to 2.8.2,
let me know.  (I'm still not completely happy with the behavior after
that patch - non-existent filenames typed in response to 'g'oto are still
not screened out as early as they should - but it would solve your
problem.)


Since you are upgrading anyway, you may want to consider going to the
current 2.8.3dev. directly (but wait for dev.14, unless you want to
apply patches by hand - should be there in a few days - see
http://sol.slcc.edu/lynx/current/).  In general it isn't any less stable
than the "released" version, esp. if you don't ./configure in the newest /
experimental options.

If you stick with 2.8.2, apply at least the patch in
<http://www.slcc.edu/lynx/release2-8-2/patches/> (but not all known
problems are fixed there, see above.)


   Klaus


reply via email to

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