On Tuesday 09 May 2006 06:18, you wrote:
Hi all,
I have a problem: I'm trying to download an entire directory from a site
and I'm using the command wget -r -I directory_name site_name.
It seems to work but at a certain point it stops but I'm sure that there
are some files missing that I can
On Wednesday 10 May 2006 09:28, you wrote:
Even in this case, how it is possible discriminate between files?
I mean, why can I download some files and I can't with others that have
similar features? It sounds strange to me...
Thanks anyway
G
Check the link:
On Thursday 20 April 2006 10:18, you wrote:
Im newbie and using a windows port of wget version 1.10.2b
I want to define wget http://fly.srk.fer.hr/ inside .wgetrc by that I want
to define several path to download like http://fly.srk.fer.hr/ inside
.wgetrc and only use the command wget which
On Thursday 20 April 2006 15:12, you wrote:
Curtis Hatter skrev:
On Thursday 20 April 2006 10:18, you wrote:
Im newbie and using a windows port of wget version 1.10.2b
I want to define wget http://fly.srk.fer.hr/ inside .wgetrc by that I
want to define several path to download like
On Friday 31 March 2006 06:52, Mauro Tortonesi:
while i like the idea of supporting modifiers like quick (short
circuit) and maybe i (case insensitive comparison), i think that (?i:)
and (?-i:) constructs would be overkill and rather hard to implement.
I figured that the (?i:) and (?-i:)
On Wednesday 29 March 2006 12:05, you wrote:
we also have to reach consensus on the filtering algorithm. for
instance, should we simply require that a url passes all the filtering
rules to allow its download (just like the current -A/R behaviour), or
should we instead adopt a short circuit
On Thursday 30 March 2006 13:42, Tony Lewis wrote:
Perhaps --filter=path,i:/path/to/krs would work.
That would look to be the most elegant method. I do hope that the (?i:) and
(?-i:) constructs are supported since I may not want the entire path/file to
be case (in)?sensitive =), but that will
