Re: wget future (was Re: Not 100% rfc 1738 complience for FTP URLs => bug
Aaron S. Hawley wrote: > On Thu, 13 Mar 2003, Max Bowsher wrote: > >>> David Balazic wrote: >>> >>> So it is "do it yourself" , huh ? :-) >> >> More to the point, *no one* is available who has cvs write access. > > what if for the time being the task of keeping track of submissions > for wget was done with its debian package? > > http://bugs.debian.org/wget > http://packages.qa.debian.org/wget > > that way, at least some of the work of incorporating and releasing and > testing these code submissions can be accomplished, making things > perhaps slightly easier when the wget authors get back. > > /end lame idea Actually, that sounds like a very *good* idea. Max.
wget future (was Re: Not 100% rfc 1738 complience for FTP URLs =>bug
On Thu, 13 Mar 2003, Max Bowsher wrote: > > David Balazic wrote: > > > > So it is "do it yourself" , huh ? :-) > > More to the point, *no one* is available who has cvs write access. what if for the time being the task of keeping track of submissions for wget was done with its debian package? http://bugs.debian.org/wget http://packages.qa.debian.org/wget that way, at least some of the work of incorporating and releasing and testing these code submissions can be accomplished, making things perhaps slightly easier when the wget authors get back. /end lame idea
Re: Not 100% rfc 1738 complience for FTP URLs => bug
David Balazic wrote: > Max Bowsher wrote: >> >> 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. > > So it is "do it yourself" , huh ? :-) More to the point, *no one* is available who has cvs write access. Max.
Re: Not 100% rfc 1738 complience for FTP URLs => bug
Max Bowsher wrote: > > 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. So it is "do it yourself" , huh ? :-) > 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 :-) -- David Balazic -- "Be excellent to each other." - Bill S. Preston, Esq., & "Ted" Theodore Logan - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Re: Not 100% rfc 1738 complience for FTP URLs => bug
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 :-)
Not 100% rfc 1738 complience for FTP URLs => bug
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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Not 100% rfc 1738 complience for FTP URLs => bug
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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
