bug-wget
[Top][All Lists]
Advanced

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

Re: [Bug-wget] General Testsuite issue


From: Tim Ruehsen
Subject: Re: [Bug-wget] General Testsuite issue
Date: Wed, 22 Jan 2014 11:13:51 +0100
User-agent: KMail/4.11.3 (Linux/3.12-1-amd64; KDE/4.11.5; x86_64; ; )

On Tuesday 21 January 2014 08:17:45 Darshit Shah wrote:
> > > The --config option is detected just before the other options by running
> > > the same loop a little earlier. However, to same CPU cycles, we break
> > > out
> > > of the loop as soon as --config is identified. I have extended that loop

What do you think, how many CPU cycles can be saved here ;-)

> > 
> > so
> > 
> > > that it detects --no-config too and breaks out the moment either one of
> > > these is seen. Hence, only the first instance is acted upon, while the
> > > others are silently discarded.
> > 
> > Thanks for making this point clear.
> > 
> > I don't understand the reason for the --config exception and I would
> > definitely implement it in a different way... but changing it will break
> > compatibility.
> 
> The reason for having the separate loop is as follows:
> 
> In case the user wants to use a config file that is not /etc/wgetrc and
> ~/.wgetrc, then they may use the --config option. However, We tend to
> initialize the settings from these files before beginning to read the
> command line arguments. This would cause wrong settings to be read from the
> default config files. Hence, we run a loop to simply check for the --config
> option and then parse the given wgetrc file before parsing the rest of the
> options.
> 
> I have simply added another check to that first loop. I too would like to
> implement this in a different manner. Do you have any ideas that we could
> use to implement this?

Well, yes. Read everything in a straight order, beginning at
        SYSCONFDIR"wgetrc"
following 'chooseconfig' directives within ('include' would be a more 
intuitive name).

Now parse the command line, whenever a --config is found, read that file 
(again following 'chooseconfig' directives).
A --reset-config would allow the user to reset all configuration variables to 
the built-in default at any time.

The 'chooseconfig' directive and the --config CLI option should allow 
wildcards (globbing with tilde, if available).
A max. recursion level prevents infinite loops (e.g. 'a' includes 'b' and 'b' 
includes 'a'). 

This would allow a /etc/wgetrc with
...
chooseconfig /etc/wgetrc.d/*
chooseconfig ~/.wgetrc
...

At least that would make the work of some distribution package maintainers 
easier and is quite clear and flexible for any user.

A user could set up his project-related and distribution independant config 
files, e.g. with
        resetconfig
        ... [special project settings]

For the test suite we simply use --reset-config as the first CLI option.

Regards, Tim




reply via email to

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