Re: [Bug-wget] General Testsuite issue

[Tim Ruehsen]

On Thursday 23 January 2014 09:03:36 Darshit Shah wrote:
> > > 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.
> > 
> > I like this idea. It may require a few changes to the Wgetrc files, but I
> 
> see how this may be a huge boon distribution packagers. Any packagers
> around here want to chime in?
> 
> "include" or "includeconfig" could be used in place of "chooseconfig".
> 
> My only issue with this idea is that it breaks backwards-compatibility with
> users' personal wgetrc files. Existing users are used to calling --config
> FILE_NAME and assuming that these settings will be applied on top of the
> compiled defaults and not the settings already existing in
> SYSCONFDIR/wgetrc.
> This requires all existing configuration files to change and add a new
> resetconfig option on top.

This shouts for a 'version' string. If there is none, Wget behaves as always.
Distribution maintainers could add this version at the beginning of 
SYSCONFDIR/wgetrc and explicitly tell about it (e.g. Debian has this mechanism 
when you upgrade a package that breaks compatibility).

If this version string can occur several times, something like the following 
adds value and keeps backwards compatibility to users (SYSCONFDIR/wgetrc):
        configversion=1.16 # 'chooseconfig' / --config adds up
        chooseconfig /etc/wgetrc.d/*
        configversion=1.15 # back to old behaviour

~/.wgetrc should be read after SYSCONFDIR/wgetrc, as it is now.

If a user wants to switch to the new behaviour, she just adds
        configversion=1.16 # 'chooseconfig' / --config adds up
to
        ~/.wgetrc

I guess that supporting wildcards won't break backward compatibility or at 
least it is very unlikely that some uses shell wildcards within config file 
names.

> I'm not so sure about how wildcards and globbing could be implemented in
> the config files. Can we somehow pass on the strings to the the shell and
> ask it to expand those for us?

I did it this way (see line 731...):
https://github.com/rockdaboot/mget/blob/master/src/options.c
(I am willing to contribute any of the code to the GNU/Wget project, if it 
comes to that point).

Tim