[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-wget] Bugs/New features
From: |
Tim Rühsen |
Subject: |
Re: [Bug-wget] Bugs/New features |
Date: |
Sat, 27 May 2017 20:14:42 +0200 |
User-agent: |
KMail/5.2.3 (Linux/4.9.0-3-amd64; KDE/5.28.0; x86_64; ; ) |
On Samstag, 27. Mai 2017 15:14:14 CEST Glacial Man wrote:
> Hi,
>
> I'm trying to use wget, on Windows, but some things are not clear for me. I
> can't call them bugs, I'm not so experienced, probably the correct
> definition is "new features". This is the problem, I'm trying to refine the
> following command (I've used uTorrent.exe's download link because it's a
> small file and I can make quick and complete tests):
>
> wget --referer="https://www.google.com" --read-timeout=15 --tries=3
> --no-check-certificate --timestamping --no-if-modified-since
> --ignore-length
> http://download.ap.bittorrent.com/track/stable/endpoint/utorrent/os/windows
>
> I can use an alternative official download link (all the rest remains
> unmodified)
>
> wget --referer="https://www.google.com" --read-timeout=15 --tries=3
> --no-check-certificate --timestamping --no-if-modified-since
> --ignore-length
> http://download-lb.utorrent.com/endpoint/utorrent/os/windows/track/stable
>
> My need is to update the local file (uTorrent.exe) when a new version is
> available on the official website. It works but:
>
> 1) The name of the downloaded file is "windows." (or "stable."), probably
> because are not available static links but server requests only. How can I
> indicate to wget (used with --timestamping option) that the local file
> name's must be "uTorrent.exe"? (as if I download it using a browser)
> Pratically, how can I indicate to wget (used with --timestamping option)
> the path of the local file?
Add --content-disposition, since the server sends the file name via the
Content-Disposition header (see --debug output).
> 2) The exit codes are very important. 0 (zero)
> means "no problems occurred", so wget exit code is 0 in the following
> cases: - 0a) downloaded (when the local file was not available)
> - 0b) updated (when the remote file's timestamp is newer than the local
> file's timestamp) - 0c) already up to date, download not needed (when the
> timestamp is the same for local file and remote file) when I use the
> --timestamping option, I need to manage the different cases to know what's
> occurred and, for example, to write in a log file 3) The same for the
> --spider option, I need to know if the file is: - downloadable (local file
> not available)
> - updatable (different timestamp)
> - already up to date (same timestamp)
On *nix you would do this with a (more or less simple) script.
When working on Windows, the first thing I do is installing Cygwin und using
bash :-)
But I guess you need the help of some ms-dos scripter here.
The basic rules are clear:
- does the file already exists
no: 'downloadable'
yes: get the timestamp of the existing file (timestamp1)
start wget with your options and --spider and --debug, get
timestamp2 from the 'Last-Modified' HTTP response header,
compare timestamp1 and timestamp2
> Thanks for wget and for your help.
Thanks for saying that :-)
With Best Regards, Tim
signature.asc
Description: This is a digitally signed message part.