lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev suggested addition to lynx.cfg


From: Klaus Weide
Subject: Re: lynx-dev suggested addition to lynx.cfg
Date: Tue, 13 Jul 1999 20:16:11 -0500 (CDT)

On Tue, 13 Jul 1999, Vlad Harchev wrote:
> On Tue, 13 Jul 1999, Klaus Weide wrote:
> > On Tue, 13 Jul 1999, Vlad Harchev wrote:
> > > On Mon, 12 Jul 1999, Klaus Weide wrote:
> > > 
> > > > I suggest the following be added at the end of lynx.cfg:
> > > > [ ... ]
> > > > #INCLUDE:~/.lynx.cfg
> > 
> > ...and there is some conversation prompting me to that suggesting
> > archived under <http://www.debian.org/Bugs/db/pa/llynx.html>,
> > Vlad please read #16214.
> 
>  OK, before reading that background I had the question "Why?" - not what the
> name it should have.
> >[...] 
> > in addition to removing (mostly) VMS-specific text.  (For the exec/cgi
> > stuff it's just making the "safer" defaults explicit by uncommenting
> > them.)  You can find the diff here:
> > <http://ftp.debian.org/debian/dists/unstable/main/source/web/lynx_2.8.2-1.diff.gz>.
>  
>  Seems wise guys are making Debian... 

Well, at least I don't regard the decision to change the default colors
in the default /etc/lynx.cfg as "wise".  It seems to be the no.1 reason
why Debian lynx users, even those who wouldn't otherwise think of touching
lynx.cfg, want to override something.  But I don't want to get into that
kind of discussion too much, it's also about "taste", If the distribution
(here, Debian package maintainer) wants to do that they can.  As long
as the users who don't like it complain only to Debian and not to lynx-dev,
which seems to be the case.

> Nevertheless, seems that users that
> switch between distributions very often move ALL their private setup - even 
> $HOME - so entire lynx.cfg will be replaced (by using $LYNX_CFG or
> replacing the file phisically), so seems the statement you suggest won't make
> the effect you wish to achive (ie helping people moving from one distribution
> to another).

Yes yes, it doesn't give any sort of guarantee of anything, but I still
think suggesting a name for this kind of setup (if people want to use
it) is better than not suggesting a name.  If only to make someone stop
and think before just picking ".lynxrc".

>  BTW, if debian distribution is so secure, seems adding explicit
> 'INCLUDE:~/.lynx.cfg' line will make it less secure from some POV.

See below...

> > >  IMO this proposal breaks several traditions (eg 2 different configuration
> > > files for in one directory for one software package, but agree that 2nd 
> > > file 
> > > is allowed not to exist).
> > 
> > One file (.lynxrc) is a file created and maintained by lynx, at least
> > that's what it's meant to be.  The other (.lynx.cfg in my proposal)
> > is maintained by the user if he/she wishes so.  They are not configuation
> > files in the same sense.
> 
>  This is not bad idea to allow users to use configure more settings of lynx.
> But it seems to me that the best solution to add the text you propose,
> commenting last line (the very INCLUDE line) - so it won't break something and
> it will notify users about the powerful approach they can use.

That was exactly the intention - the file should be shipped with the
"INCLUDE" commented out as "#INCLUDE".  Definitely it should be shipped
that way by lynx-dev, if a distribution wants to enable it by default
(instead of leaving as a comment for users) it's their choice but I
wouldn't recommend it.

I realize now that my sentence

   # If an installation or distribution uses a (properly modified) copy
   # of this file as a system-wide default, but wants to allow [...] 

could encourage a packager too much to remove that '#', so probably
the words "or distribution" should be omitted (or be put in parentheses
(maybe I like parentheses too much)).
 
> >[...]
> > 
> > It's also inconvenient to have to set LYNX_CFG.  (Try to describe in one
> > sentence to a new user which files to modify, taking all possible
> > login shells into account.)
> 
>  I agree that modifying LYNX_CFG is a bad hack.

It's the right thing for those users who really want to have full control -
the "power users" you mentioned earlier. (but not necessarily that much
"power" that they want to (or can) compile their own.)

> > > IMO we should start README.packager (IMO better to have it at the top of
> > > tree) file and describe there what are recommended switches to configure, 
> > > what
> > > are recommended default lynx.cfg settings - in 'for impatient' manner - 
> > > this
> > > will help packagers a lot.
> > 
> > Good idea, please do so.  Although one would hope that packagers notice
> > differences in lynx.cfg ...
> 
>  I hope we will add this file :) Seems we have a lot of time before 2.8.3 is
> released.
>
> >[...] 
> 
>  So, my conclusion: we can add this text, but IMO commenting the very INCLUDE
> line.

As I said, that was the idea.

     -----
I wrote earlier that I don't care about what the suggested filename is,
but now I think that "~/.lynx.cfg" can still invite people to make bad
assumptions - the name encourages users to just copy the system-wide
/etc/lynx.cfg or /usr/local/lib/lynx.cfg to their home directory and
then change only what they want to change in that copy.  That will
fail at least for the "INCLUDE" itself, if the user doesns't remove
it... (I havent' checked how the code deals with such a loop).

So the name should indicate that the file is 'included' by something
else.  I suggest .lynx.cfg-inc, maybe someone has a better idea?

(I don't think the more-than-three-character file extension is an
issue, the text already limits the suggestion to "Unix-like systems",
and no such file will actually be included in a lynx source .zip .)

>  Is your clock correct, Klaus? 

As far as I know. :)   It may be off a few seconds...

   Klaus


reply via email to

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