As I got no response on [EMAIL PROTECTED], I am resending my report here. --
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 :-) -- David Balazic -------------- "Be excellent to each other." - Bill S. Preston, Esq., & "Ted" Theodore Logan - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
