lynx-dev
[Top][All Lists]
Advanced

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

LYNX-DEV Multiple lynx.cfg files (was: reorganizing the lynx-archive)


From: Will Mengarini
Subject: LYNX-DEV Multiple lynx.cfg files (was: reorganizing the lynx-archive)
Date: Tue, 12 Nov 1996 05:03:31 -0800 (PST)

address@hidden (David Combs) writes:

>SUGGESTION: re lynx.cfg

>How about a second option for lynx.cfg on cmd line: +cfg
>  with the "+" implying that we want our local lynx.cfg
>  to be ADDED ONTO the standard one.

>That is, with the "+", it first reads in the standard one,
>  THEN reads in the local one, overriding only those items
>   specified by the local one.

>(This means that there must be a way to turn OFF features
>  that were turned ON by the standard one.  Maybe that's
>  already there?)

>the BENEFIT of this change is that on a system where the
>administrator (someone other than the user) makes changes
>to the standard lynx.cfg, the user gets the benefit of
>those automatically.  Otherwise he has to keep looking
>at the date of the standard one to see if it has changed
>since he copied it to his own directory, has to diff it,
>etc, etc.  This is much easier.

I've been thinking about this for a while.  My ISP has over FIVE
different lynx.cfg files scattered in various ancient public
directories, because nobody currently on staff remembers what they
were for & everybody is afraid to delete them.  Furthermore, the
actual changes made by this site are trivial--one or two lines.  It
would be enormously more convenient for them to be in a separate file.

I think the best design would be for everyplace a name can be given to
the lynx.cfg file (e.g. $LYNX_CFG) to allow a list of names separated
by ":" (the same character used to separate directories in $PATH on Unix).
The files would be read in sequence, so later files in the list would
override earlier ones.

The default, now "/usr/local/lib/lynx.cfg", should probably become
"./lynx.cfg:/usr/local/lib/lynx-site.cfg:/usr/local/lib/lynx.cfg".
Installation instructions would explain that only modified lines should
go in lynx-site.cfg.

Discuss.

During the heyday of Lynx2-#-FM development, when I'd build a
new Lynx every few days, I found constantly updating my lynx.cfg
to be a real pain, since diff/patch kept failing multiple blocks
because I'd changed so much.  I ended up leaving the body of
lynx.cfg unchanged, & always putting my all my .cfg stuff in a
trailer at the end of lynx.cfg, so it was a single block that
diff/patch could always find.  In other words, if there was a
  SOME_RANDOM_ATTRIBUTE:default_foo
line in the default lynx.cfg, I'd leave it there in my lynx.cfg;
but farther down in the file, in the trailer, the line
  SOME_RANDOM_ATTRIBUTE:my_foo
would override it.  This was functionally equivalent to multiple files.
However, every time (every other day!) on which Fote would add a new
attribute at the end of the default lynx.cfg, diff/patch would consider
that to belong *after* the trailer instead of before, so I needed a gawk
script to move the trailer back to the end of the file.  That sucked, &
the fact that I was willing to go to the trouble suggests that multiple
lynx.cfg files would be worth supporting.

But if you find the current patch anarchy a bit forbidding (I do) and
want to implement the trailer kluge pending support for multiple
lynx.cfg files, here's the gawk script.
----------------------------<bin/movetrailer>---------------------------
#!/usr/local/bin/gawk -f

# movetrailer - Takes a block of text beginning with a line containing
# "BEGIN TRAILER BLOCK" & ending with a line containing "END TRAILER BLOCK"
# (delimited by sharps or splats) & moves it to the end of the file,
# regardless of where in the file it was found.

{
  if( $0 ~ "[#*]BEGIN TRAILER BLOCK[#*]" ){
    trailer[i++] = $0
    inTrailer = 1
  }else if( $0 ~ "[#*]END TRAILER BLOCK[#*]" ){
    trailer[i++] = $0
    inTrailer = 0
  }else if( inTrailer ){
    trailer[i++] = $0
  }else{
    print
  }
}

END {
  while( j < i ) print trailer[j++]
  # Note that "for( j in trailer )" would fail because iteration over
  # subscripts would be in random order.
}
------------------------------------------------------------------------

--
Will Mengarini <address@hidden> This .sig has been accessed [INLINE] times

"Today's Price [INLINE]"
      --Insight Direct's Home Page <http://www.insight.com> Tu 12 Nov 96
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;



reply via email to

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