On Thu, Jan 23, 2014 at 2:47 PM, Tim Ruehsen 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"
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' wo
> > > 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 ca
Darshit Shah writes:
> Till we decide on a restructure, here is the patch for --no-config.
>
> This patch is made against master, but is required in parallel-wget too.
> @Giuseppe: Maybe you could cherry pick this? Or merge master into
> parallel-wget, especially since we've just released a new v
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
Till we decide on a restructure, here is the patch for --no-config.
This patch is made against master, but is required in parallel-wget too.
@Giuseppe: Maybe you could cherry pick this? Or merge master into
parallel-wget, especially since we've just released a new version.
On Tue, Jan 21, 2014 a
>
> > 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
> so
> > that it detects --no-config too and breaks out the momen
On Saturday 18 January 2014 23:51:07 Darshit Shah wrote:
> On Sat, Jan 18, 2014 at 2:05 AM, Tim Rühsen wrote:
> > Am Freitag, 17. Januar 2014, 11:42:41 schrieb Tony Lewis:
> > > Darshit Shah wrote:
> > > > In case both the --config and --no-config commands are issued, the one
> > >
> > > that
> >
On Sat, Jan 18, 2014 at 2:05 AM, Tim Rühsen wrote:
> Am Freitag, 17. Januar 2014, 11:42:41 schrieb Tony Lewis:
> > Darshit Shah wrote:
> > > In case both the --config and --no-config commands are issued, the one
> >
> > that
> >
> > > appears first on the command will be considered and the other
Am Freitag, 17. Januar 2014, 11:42:41 schrieb Tony Lewis:
> Darshit Shah wrote:
> > In case both the --config and --no-config commands are issued, the one
>
> that
>
> > appears first on the command will be considered and the other ignored.
>
> Given my memory of the way the parsing loop works,
Darshit Shah wrote:
> In case both the --config and --no-config commands are issued, the one
that
> appears first on the command will be considered and the other ignored.
Given my memory of the way the parsing loop works, I would expect that it
would use the last one that appears. How do GNU comm
Hi Tim,
Yes, that is an eventuality I did not consider when writing this test. A
user configured option that may override the settings intended for the
test. Maybe we should have a --no-config option to ensure that the tests
are run on the compiled defaults only.
Having a uniform environment for
Hi,
I just discovered that Test--spider-r.py fails here (parallel-wget branch).
The reason is 'robots=off' in ~./wgetrc.
But that leads the the question, how can we prevent any user (and global
/etc/wgetrc) settings dropping in, possibly making the tests fail.
An option like --no-config could
13 matches
Mail list logo
