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: Thu, 23 Jan 2014 09:03:36 +0530

> > > 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 ;-)
>
> Well, this was always there. I simply extended it. I hated the fact that
when neither of --config and --no-config were passed, this loop would parse
all the arguments to Wget and do nothing about it. It is high time that
this be changed.

Agreed, the way I took wasn't saving too many cycles, but preventing the
exception would have required a little more logic and it didn't seem worth
the effort.

> 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.
>
> 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.

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?

In http.c we already have the logic for handling cyclic dependencies.
Simply need to extend it to handle cyclic dependencies in the config files.
I like the direction in which this is going expect for the slight breakage
in wgetrc compatibility. Maybe we can engineer something to fix that?

-- 
Thanking You,
Darshit Shah


reply via email to

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