On 29/11/11 17:28, Zachariah Yoder wrote:
Dear developers of WGET,
Thank you for a useful tool. The operation is intuitive and easy to use.
With the advent of Windows 7, however, users who save wget.exe in
their program files directory will be confused as to where the files
are saved.
From: Zachariah Yoder zach_yo...@wycliffe.org
Dear developers of WGET,
Thank you for a useful tool. The operation is intuitive and easy to use.
With the advent of Windows 7, however, users who save wget.exe in their
program files
directory will be confused as to where the files are
this may have something to do with working directory which when an
exe is run from a shortcut, uses the exe folder as the default path.
Some testing on win7 is needed to clarify this issue, as that Program
Files path is used for 32bit apps on 64bit installation..
Paul
On Thu, Dec 1, 2011 at 5:34
another command line option possibly?
Paul
2011/11/30 Andrew Daviel ad...@triumf.ca:
On Sat, 26 Nov 2011, Ángel González wrote:
On 10/11/11 03:24, Andrew Daviel wrote:
When downloading a large file over a high-latency (e.g. long physical
distance) high-bandwidth link, the download time is
From: Paul Wratt paul.wr...@gmail.com
this may have something to do with working directory which when an
exe is run from a shortcut, uses the exe folder as the default path.
Some testing on win7 is needed to clarify this issue, as that Program
Files path is used for 32bit apps on 64bit
2011/11/29 Andrew Daviel ad...@triumf.ca:
but I became recently aware of download accelerators designed primarily to
thwart bandwidth allocation/throttling. Interestingly Wget is listed on the
Wikipedia page as a download manager, implying it can already do this.
the result of this is --force-clobber is used
On Mon, Nov 21, 2011 at 7:43 PM, Paul Wratt paul.wr...@gmail.com wrote:
at the moment if you try a recursive wget with --no-clobber
--convert-links the --no-clobber is discarded in favour of
--convert-links
This is incorrect as --no-clobber
On Wed, Nov 9, 2011 at 23:24, Andrew Daviel ad...@triumf.ca wrote:
When downloading a large file over a high-latency (e.g. long physical
distance) high-bandwidth link, the download time is dominated by the
round-trip time for TCP handshakes.
Which is why large files should be stored on FTP
unfortunately there are now a lot of services offered where ftp access
is not provided, or not available, or even blocked. About 90% of the
servers I mirror fit into this category
On Thu, Dec 1, 2011 at 6:43 AM, Fernando Cassia fcas...@gmail.com wrote:
On Wed, Nov 9, 2011 at 23:24, Andrew Daviel
Could this be solved by having wget do a change to cwd, when running on
windows. Or something like that?
/henrik holst
Den 30 nov 2011 18:31 skrev David H. Lipman dlip...@verizon.net:
From: Paul Wratt paul.wr...@gmail.com
this may have something to do with working directory which when an
A cwd to where? Normally one wants to download into the current
directory (particularly if you have placed wget's location in the PATH).
If you want it somewhere else, just use the -P option.
-mjc
(2011年11月30日 10:31), Henrik Holst wrote:
Could this be solved by having wget do a change to cwd,
I dont have a win7 install to test this atm, altho I do agree with
this comment, win7 does handle 32bit apps on 64bit install differently
(that may include a modified path)
@Henrik
no, but someone needs to verify use on 64bit win7. On other win it
performs as expected. I expect there is a problem
On Wed, 30 Nov 2011, Fernando Cassia wrote:
When downloading a large file over a high-latency (e.g. long physical
distance) high-bandwidth link, the download time is dominated by the
round-trip time for TCP handshakes.
First off, this early conclusion is incorrect. RTT has basically no
I might not understand the problem then (not a win user), but on my system
I very much want wget to download the files to the current directory (of my
user). And that is also how it works under Linux.
Or does current directory mean where the exe is under win? If so then I
of course meant the
this change in behaviour was introduced in 1.13+
On Thu, Dec 1, 2011 at 6:41 AM, Paul Wratt paul.wr...@gmail.com wrote:
the result of this is --force-clobber is used
On Mon, Nov 21, 2011 at 7:43 PM, Paul Wratt paul.wr...@gmail.com wrote:
at the moment if you try a recursive wget with
Ah, having tread the whole thread... I now see that this is when running
wget from a desktop shortcut?
Den 30 nov 2011 19:40 skrev Henrik Holst henrik.ho...@millistream.com:
I might not understand the problem then (not a win user), but on my system
I very much want wget to download the files to
the initial post is unclear on how wget is initiated, but it implied
non-commandline use in my view.
I agree with other post, if run from cmd or run box it should
perform as expected, (I have used the script from --no-clobber
--convert-links thread successfully on win7 64bit), but I think there
From: Henrik Holst henrik.ho...@millistream.com
Ah, having tread the whole thread... I now see that this is when running
wget from a desktop shortcut?
One would not run it from a shorcut unless you created a script that called
WGET.
Windows doesn't have a default folder per se. It is up to
On 30/11/11 18:31, David H. Lipman wrote:
If the command is NOT in the PATH then you have to be in the directory where
the command
exists and when you run the command it will drop the downloaded files there.
When the
command and dependencies are in the PATH then all I have to do is open
From: Zachariah Yoder zach_yo...@wycliffe.org
With the advent of Windows 7, however, users who save wget.exe in their
program files directory will be confused as to where the files are saved.
Could you add a line in the wget help directing users either to:
20 matches
Mail list logo
