LYNX-DEV chaining lynx.cfg files

[Bela Lubkin]

Will Mengarini wrote:

Will> Another one I'd like to do is multiple .cfg files (by putting
Will> a colon-separated list of filenames in $LYNX_CFG, analogous
Will> to $PATH).  This would make it easier for sites to keep
Will> their tweaks separate from the main .cfg, which needs to
Will> remain up-to-date because it contains a lot of documentation.

How would this be better than allowing an "include" statement in a
lynx.cfg file?

Your way:

  LYNX_CFG=/wherever/the/system/keeps/it/lynx.cfg:$HOME/lynx.cfg

My way:

  LYNX_CFG=$HOME/lynx.cfg

  Inside $HOME/lynx.cfg:

    include /wherever/the/system/keeps/it/lynx.cfg
    my own changes

I thought this had been discussed previously and it was agreed that it
was a good idea, but nobody has submitted patches to implement it.

The include statement allows more flexibility -- you could include
various fragments, nest things, choose to allow the system lynx.cfg
override some of your options (by putting them at the top, before the
system), etc.  I would suggest an immediate enhancement, that the
include statement should know a magic name for the system default
lynx.cfg.  So I could do:

  include <lynx.cfg>    # as with C, "<>" means "the system's default place"
  my own generic, cross-system changes
  include $HOME/local-machine-lynx.cfg  # no <> means "user-specified place"
                                        # also allow "" for congruence w/C

The same lynx.cfg would be much more portable to multiple systems.

Larry W. Virden wrote:

Larry> The one thing of concern would be security.  If a site locked down
Larry> the permission to perform certain operations, lynx should take the most
Larry> restrictive of the settings it encounters as it passed thru the list
Larry> of lynx.cfg; otherwise a hacker could open up her/his account.

If the hacker is able to set LYNX_CFG, all is already lost.  Likewise,
if the hacker is able to edit the file pointed to by $LYNX_CFG, all is
lost.  So I don't see where either implementation adds a new security
concern.

>Bela<
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;