Re: lynx-dev Proposed patch (DOS related)

[Leonid Pauzner]

10-Oct-98 11:47 HN wrote:

>> environment or from command-line. The 'LYNXCFG_HELP' was supposed to point us
>> out to clear distribution's lynx.cfg as a source for about 90Kb of comments
>> (LYNX_CFG_FILE from autoconf seems to be a best candidate on UNIX).
   ^^^^^^^^^^^^^ I suppose this file may be modified slightly,
                 not exactly as from distribution. But it
                 (almost) definitely exist and complete.
                 And this looks useful for UNIX users without privileges
                 who may be not sure where certain files located etc.
                 (no problem for you if you maintain your own system).
                 We need probably check fopen(LYNX_CFG_FILE, "r") for sure.

> Yes/No.  In my particular situation disk space comes at an extreme premium.
> Therefore before even running autoconf, I switch my 1300 byte lynx.cfg for
> the huge distribution one.  In other words I fool autoconf into installing
> my custom lynx.cfg rather than the distribution one.  I do the same with
> the main help menu because I need a door to two sets of help (ja and en).

> Concerning the
> annotated lynx.cfg, it could be set to point to "http://www.slcc.edu/lynx/
> current/lynx2-8-1/lynx.cfg", much as the default help points to "http://
> www.crl.com/~subir/lynx/lynx_help/lynx_help_main.html".  Of course we should
> get Scott's okay on something like this.

I was thinking of it. If someone use lynx_help from remote http:// source
but not from local files - lynx.cfg will be found currently
if located in lynx_help directory. But we should care
of localhost users either. So, this questions may need
some more fooling for finding an optimal variant (this is not
a coding problem, just a consensus on the lynx-dev).


> Just rambling for 2-8-2.

> __Henry


10-Oct-98 07:12 DK wrote:

>> > I am having trouble understanding the logic behind the display of
>> > lynx.cfg in LYReadCFG.c. It seems to try to display a lynx.cfg file,
> I follow what you are saying, but disagree with the reasoning. The
> question of following an INCLUDE directive is moot if the file
> being rendered is NOT the active lynx.cfg, but rather a copy of the
> distribution's lynx.cfg which has been saved unmodified. The change
> to include a subfile will be in the active lynx.cfg. In most cases,
> this will be the address from userdefs.h. Neither the individual user
> nor a system administrator needs to keep lynx.cfg at this location,
> however. If lynx.cfg is at another location, the current code will not
> find it. "lynx_cfg_file", however, ALWAYS points to the configuration
> file currently being used, which should have all the comments and
> any links to included files.

NO. "currently used" lynx_cfg_file may INCLUDE other file
in its first line (exactly as on my system) and therefore be without comments.


> administrators won't) keep a duplicate copy of lynx.cfg just for the
> help system to find. If the worry is that the active file will be
> shortened to only the items that are different from the compilation
> option, it is easier to specify in the INSTALLATION instructions that
> the file should not be shortened because it is also a help file, than
> to ask that a duplicate file be kept at a hardcoded help location.

too complicated^^^^^

> Perhaps I am missing some implications of the current code. What
> allows lynx to follow included files now, which doesn't work after the
> proposed patch?
You will lost a link from "Lynx.cfg Information Page",
nothing more serious, especially if you do not read it.

>                               Doug