Re: lynx-dev patch to add description of extended INCLUDE syntax to lynx.cfg

[Vlad Harchev]

On Mon, 31 May 1999, Henry Nelson wrote:

> > This patch adds description of extended INCLUDE syntaxt to lynx.cfg and 
> > also 
> 
> Man, did I let out a sigh when this came over.  Just when we're so close to a
> release.  But I'm going to forge ahead.  Why?  Because this INCLUDE, AFAICT,
> is the only real justification Vlad has for tacking on the CFG help.
> 
> > +# Starting from Lynx 2.8.2 INCLUDE facility became yet more powerful. It's 
> > +# possible to reduce the set of settings that will be read from included 
> > fil
> [...]
> > +# (ie there is no security hole in including user-defined configuration 
> > file 
> > +# if a set of allowed settings is secure).
> 
> Think about what this really means in terms of making the status of
> configuration settings more difficult to determine.  Although it is
> stated that it is "possible to reduce the set of settings that will be read"
> from a single file, there is no limit to the number of those files nor
> is there any restriction on their location.  It carries flexibility
> to the point of anarchy.  Now you need a tracking system to figure out
> just where a setting was made.

 You are free not to use extended include syntax - old syntax will work.

> Before INCLUDE syntax was added, all a person had to know was 1) compile
> time options, 2) environment variables in .profile or .cshrc, 3) command-
> line options, 4) content of .lynxrc readily apparent in the options menu,
> and 5) settings in lynx.cfg.
> 
> Don't get me wrong, a mechanism to use the defaults of the system lynx.cfg
> and just add on or override those settings one has a personal preference for,
> all in *ONE* little file is a very good idea.  I thought that's what we were
> getting with INCLUDE, and I'd bet a lot of other unwary lynxdevers thought
> the same.  It means adding only one more place, making the total 6, that
> someone need look to debug their settings.  The point of the INCLUDE idea
> is that a person WANTS to use what are probably sensible defaults for a
> particular system, and only wants to amend or add a FEW personal preferences.
> The INCLUDE file by definition will be short and simple.  If the system
> lynx.cfg is junk, then a person wants to replace the whole thing and start
> with a fresh one.  There is no need for INCLUDE in that case.
> 
> My recommendation is to simplify the INCLUDE syntax rather than to have
> something implemented that is so complex that it requires lengthy explanations
> for a typical user to understand and make good use of it.

 IMO simplifying syntax is bad idea because:
1) It can't be done for sake of backward compatibility
2) It's powerful thing and it's mostly targeted to ISPs that provide "lynx
   account" to their users - without this setting, user was unable to select
   colors (if compiled without lss) since COLOR setting is initialized in
   lynx.cfg - with this setting, sysadmin can allow inclusion of user-written
   file, so that only several settings will be read from it (eg COLOR,KEYMAP)
   and some other settings that are key for security like TRUSTED_EXEC will be
   safely ignored. So extending INCLUDE syntax allows user to fine tune lynx
   by settings not only in .lynxrc, but by some in lynx.cfg, with security in
   mind. If you as sysadmin INCLUDE user-written file without extended syntax,
   then you have a risk of havving security hole. So, without extended INCLUDE
   syntax sysadmin from the following 2 way
      a) provide a user the ability to control lynx settings by including
         user-defined configuration file (making security hole)
      b) restricting user from fine-tuning lynx making it more pleasant to 
         work with lynx for user
  definitely was choosing b)
  Now with extended include syntax it's possible to choose a) without security 
  risks.

3) It's not targeted for people that use their computer personally.
4) I don't understood you about tacking CFG help - do you mean that 
 a) This is a only one thing LYNXSETTINGSTATUS is useful for
 b) I have written description of INCLUDE syntax to provide a patch to
    lynx.cfg that adds references to www.hippo.ru/~hvv/lynxcfg_toc.html
 As for a) - LYNXCFG:// page already (from dev 23) upports this nicely -
 check it. As for b) - there were no description of extended INCLUDE syntax in
 lynx.cfg, so I added it. I think reference to www.hippo.ru will also help
 some users.
5) Seems that 80% of users don't read their lynx.cfg if lynx works ok so 
  stupid people won't be confused due to their stupidity.
6) Seems you are still crazy 

 So this extended include syntax allows to initialize settings that are beyond
.lynxrc in a very safe way for systems with any number of users.
 If you have found the description too complex (and understood what that
syntax means) please write another - I don't insist on my description of
INCLUDE syntax. Somewhat longer description exists in CHANGELOG for dev23.
 
 Better think when you post anything. Seems that you are reading and writing
to lynx-dev due to absence of work - seems you are just adminning. Please
think carefully about each feature that was added to lynx (and then 
possibly say you think here) rather than blindly sending critics to each
message that has my name in "From" field (or to each feaure you don't have
time to understand) - remember - you are free not to use ALL lynx features.
If you don't need them, it doesn't mean that nobody does too.
 
>[...]
 Best regards,
  -Vlad