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: Darshit Shah
Subject: Re: [Bug-wget] General Testsuite issue
Date: Sat, 25 Jan 2014 09:34:37 +0530

On Thu, Jan 23, 2014 at 2:47 PM, Tim Ruehsen <address@hidden> wrote:

> 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).
>
Personally, I loathe the idea of version strings. Deprecating old usage of
the conf files becomes very difficult and we need to maintain multiple
parsers for different versions.

However, I don't currently see a better option. Once implemented, this
patch should speed up the invocation of Wget and we'll have a much cleaner
main function.

>
> 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).
>
> I see that you have the recursion level management and globbing expansion
both written for mget. We could probably use the same logic here again.


I am planning on starting work for this set of patches on a local
repository. I'll be pushing my code to GitHub till we have a tested and
debugged rewrite, which can later be pushed to master. The in-work patches
can be found here:
https://github.com/darnir/wget/tree/rewrite_input
Any patches to this branch are most welcome!

Currently, I'm a little busy with my undergrad thesis and will not be able
to devote much time to this right now. However I will continue working on
it whenever time allows.


-- 
Thanking You,
Darshit Shah


reply via email to

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