David Balazic wrote: > As I got no response on [EMAIL PROTECTED], I am resending my report > here.
One forwards to the other. The problem is that the wget maintainer is absent, and likely to continue to be so for several more months. As a result, wget development is effectively stalled. Max. > > -- > > Hi! > > I noticed that wget ( 1.8.2 ) does not conform 100% to RFC 1738 when > handling FTP URLs : > > wget ftp://user1:[EMAIL PROTECTED]/x/y/foo > > does this : > > USER user1 > PASS secret1 > SYST > PWD ( let's say this returns "/home/user1" ) > TYPE I > CWD /home/user1/x/y > PORT 11,22,33,44,3,239 > RETR foo > > Why does it prepend the current working directory to the path ? > > wget does "CWD /home/user1/x/y" , while RFC 1738 suggests : > CWD x > CWD y > > ? > > This _usually_ results in the same results, except : > > - ftp://user1:[EMAIL PROTECTED]//x/y/foo > wget : CWD /x/y > rfc : > CWD # empty parameter ! this usually puts one in the $HOME > directory > CWD x > CWD y > > So wget will try to fetch the file /x/y/foo , while an RFC > compliant > program would fetch $HOME/x/y/foo > > - non unix and other "weird" systems. Example : > > wget > "ftp://user1:[EMAIL PROTECTED]/DAD4%3A%5Bperl5%5D/FREEWARE_README.TXT" > > does not work. Also the following variations don't work either : > > wget > "ftp://user1:[EMAIL PROTECTED]/DAD4:[perl5]FREEWARE_README.TXT" > wget > "ftp://user1:[EMAIL PROTECTED]/DAD4%3A%5Bperl5%5DFREEWARE_README.TXT" > wget > "ftp://user1:[EMAIL PROTECTED]/DAD4:/perl5/FREEWARE_README.TXT" > > Using a regular ftp client , the follwoing works : > > open connection & log in : > > - first possibility : > > get DAD4:[perl5]FREEWARE_README.TXT > > - second : > > cd DAD4:[perl5] > get FREEWARE_README.TXT > > Another example with more directory levels : > > get DAD4:[MTOOLS.AXP_EXE]MTOOLS.EXE > or > cd DAD4:[MTOOLS.AXP_EXE] > get MTOOLS.EXE > or > cd DAD4:[MTOOLS] > cd AXP_EXE > get MTOOLS.EXE > > > I recommend removing the "cool&smart" code and stick to RFCs :-)
