Keith Moore wrote:
> In that case, "--no-redirections" makes much more sense.
I've attached the "--no-redirections" version of the patch.
KM
diff -uprN -x .svn wget.orig/doc/ChangeLog wget/doc/ChangeLog
--- wget.orig/doc/ChangeLog 2005-11-25 14:01:03.5 -0600
+++ wget/doc/ChangeLog
From: Hrvoje Niksic
> Prepending is already there,
Yes, it certainly is, which is why I had to disable it in my code for
VMS FTP servers.
> and adding it fixed many problems with
> FTP servers that log you in a non-/ working directory.
Which of those problems would _not_ be fixed by my t
Hrvoje Niksic wrote:
> Actually the switch would technically be named "redirections", default
> to "on", and would be turned off using "--no-redirections" or
> "--redirections=off". The wgetrc command would be something like
> "redirections=[on|off]".
Ahh... I didn't realize the "no-foo" handlin
Daniel Stenberg <[EMAIL PROTECTED]> writes:
> On Fri, 25 Nov 2005, Steven M. Schweda wrote:
>
>> Or, better yet, _DO_ forget to prepend the trouble-causing $CWD to
>> those paths.
>
> I agree. What good would prepending do?
Prepending is already there, and adding it fixed many problems with
FTP
Keith Moore <[EMAIL PROTECTED]> writes:
> Now that I think about it, I'm convinced the switch should be
> named something more "positive". Seeing "--no-redirections" on the
> command-line makes perfect sense, but I would really hate to see
> "no_redirections=on" in the .wgetrc file.
Actually the
On Fri, 25 Nov 2005, Steven M. Schweda wrote:
Or, better yet, _DO_ forget to prepend the trouble-causing $CWD to those
paths.
I agree. What good would prepending do? It will most definately add problems
such as those Steven describes.
--
-=- Daniel Stenberg -=- http://daniel.haxx
From: Hrvoje Niksic
> Also don't [forget to] prepend the necessary [...] $CWD
> to those paths.
Or, better yet, _DO_ forget to prepend the trouble-causing $CWD to
those paths.
As you might recall from my changes for VMS FTP servers (if you had
ever looked at them), this scheme causes no en
Mauro Tortonesi wrote:
> hi keith,
>
> i have discussed your patch with hrvoje. we both agree that a
> --max-redirections option would be too low-level for Wget, and that the
> best solution to your problem would be to add a --no-redirections switch
> instead.
>
> would you like to modify your p
Hrvoje Niksic <[EMAIL PROTECTED]> writes:
> That might work. Also don't prepend the necessary prepending of $CWD
> to those paths.
Oops, I meant "don't forget to prepend ...".
Mauro Tortonesi <[EMAIL PROTECTED]> writes:
> Hrvoje Niksic wrote:
>> Arne Caspari <[EMAIL PROTECTED]> writes:
>>
>> I believe that CWD is mandated by the FTP specification, but you're
>> also right that Wget should try both variants.
>
> i agree. perhaps when retrieving file A/B/F.X we should try
Thank you all for your very fast response. As a further note: When this
error occurs, wget bails out with the following error message:
"No such directory foo/bar".
I think it should instead be "Could not access foo/bar: Permission
denied" or similar in such a situation.
/Arne
Mauro Tortones
Hrvoje Niksic wrote:
Arne Caspari <[EMAIL PROTECTED]> writes:
I believe that CWD is mandated by the FTP specification, but you're
also right that Wget should try both variants.
i agree. perhaps when retrieving file A/B/F.X we should try to use:
GET A/B/F.X
first, then:
CWD A/B
GET F.X
if t
Arne Caspari <[EMAIL PROTECTED]> writes:
> When called like:
> wget user:[EMAIL PROTECTED]/foo/bar/file.tgz
>
> and foo or bar is a read/execute protected directory while file.tgz is
> user-readable, wget fails to retrieve the file because it tries to CWD
> into the directory first.
>
> I think th
Hello,
current wget seems to have the following bug in the ftp retrieval code:
When called like:
wget user:[EMAIL PROTECTED]/foo/bar/file.tgz
and foo or bar is a read/execute protected directory while file.tgz is
user-readable, wget fails to retrieve the file because it tries to CWD
into the
14 matches
Mail list logo
