On Thursday, February 6, 2014, Tim Ruehsen <[email protected]> wrote:
> Hi Yousong, > > please don't forget to send your posts to the mailing list. Sorry for that. > > On Thursday 06 February 2014 10:27:37 Yousong Zhou wrote: > > On Wednesday, February 5, 2014, Tim Ruehsen <[email protected]> wrote: > > > First of all, thanks for your contribution. > > > > > > I have some little remarks / questions: > > > > > > - The documentation is not quite right: when using --start-pos and the > > > file > > > already exists, wget creates as expected a file.1. > > > But your docs say, --start-pos would overwrite an existing file !? > > > Could you make this point clear ? > > > > Yes, 'overwrite' is wrong. > > > > > - The combination with --continue works for me as expected. It would > > > simply > > > append the downloaded bytes to the existing file. Maybe you should > > > document > > > that as well. At least your sentence "... it would override the > behavior > > > of -- > > > continue" seems not to be correct. > > > > Sorry for the confusion. --continue will detect size of existing file, > > then continue as if an equivalent --start-pos was specified. By > 'override' > > I mean the new option has higher precedence over --continue. Other than > > that, all existing behaviors of wget are supposed to remain unchanged. > > > > > - What about extending the option to something like > > > --range=STARTPOS[-ENDPOS] > > > ? > > > > You mean change the option name to 'range'? IIRC, that's how curl does > it. > > I am okay with --start-pos. ;) > > I just wanted to mention a possible 'ENDPOS'. In that case --start-pos > isn't > appropriate any more and --range seems natural to me. I thought ENDPOS was in the patch and once I did a quick look at it I know why I decided it should be --start-pos, without LEN or ENDPOS. - I thought the current implementation is simple, neat and easy. Several lines of code really help at that time. - Code of wget is old and mature enough, mimicing curl's --range is very likely to pose many compatibility and maintainance issues. This is not what we want. - I actually thought about LENGTH, but not ENDPOS and the main reason I give myself to not implement it is that we can achieve length limit with other utilities, e.g. dd. So I do not have intention to implement curl-like --range option in wget. > > I just took a look at curl's man page. The curl people did it the right > way. > Especially their hint about multipart responses is of value (i didn't know > that). Such cases would likely need special handling in Wget. > > didn't know that either. > > > > > - If you want to brush up your patch, add a test-case for it for the > new > > > Python based test suite. I guess, Darshit can give you a helping hand, > if > > > you > > > request it. > > > > Will do once I get the time. > > > > > Tim > > > > Thank you for looking at this. > > > > yousong > > > > > > --start-pos is zero-based. > > > > > > > > v2 -> v3 > > > > > > > > Fix a typo and add description text for the new option into > the > > > > > > > > usage output. Thank Darshit Shah <[email protected] <javascript:;>> > for > > > > > > the suggestions. > > > > > > > v1 -> v2 > > > > > > > > It was kindly pointed out by Darshit Shah > > > > <[email protected]<javascript:;>> > > > > > > that > > > > > > > server support for resuming download is required, so adding > this > > > > > > > > into doc/wget.texi. > > > > > > > > doc/ChangeLog | 4 ++++ > > > > doc/wget.texi | 17 +++++++++++++++++ > > > > src/ChangeLog | 9 +++++++++ > > > > src/ftp.c | 2 ++ > > > > src/http.c | 2 ++ > > > > src/init.c | 1 + > > > > src/main.c | 3 +++ > > > > src/options.h | 1 + > > > > 8 files changed, 39 insertions(+), 0 deletions(-) > >
