[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-wget] [PATCH v4] Make wget capable of starting download from a
From: |
Tim Ruehsen |
Subject: |
Re: [Bug-wget] [PATCH v4] Make wget capable of starting download from a specified position. |
Date: |
Thu, 06 Feb 2014 15:50:28 +0100 |
User-agent: |
KMail/4.11.5 (Linux/3.12-1-amd64; KDE/4.11.5; x86_64; ; ) |
> > On Thursday 06 February 2014 10:27:37 Yousong Zhou wrote:
> > > On Wednesday, February 5, 2014, Tim Ruehsen <address@hidden> 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 understand that and agreed with you.
For me, there is just this little documentation issue that I mentioned (here
is my imperfect suggestion)
Start downloading at zero-based position @var{OFFSET}. Offset may be
expressed in bytes, kilobytes with the `k' suffix, or megabytes with the `m'
suffix.
If combined with @samp{--continue} and the destination file exists, the
downloaded data will be appended. To avoid appending, you may explicitly
specify an output filename with @samp{-O FILE}.
Server support for the 'Range' header is needed, otherwise @samp{--start-pos}
cannot help. See @samp{-c} for details.
Regards, Tim