> From: Zachariah Yoder
>
>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:
>C:\Users\USERNAME\AppData\Local\VirtualStore\Program
On 30/11/11 18:23, Paul Wratt wrote:
> 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 i
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 o
From: "Henrik Holst"
> 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 the application. An
app
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 ther
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" :
> 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 (o
this change in behaviour was introduced in 1.13+
On Thu, Dec 1, 2011 at 6:41 AM, Paul Wratt wrote:
> the result of this is --force-clobber is used
>
> On Mon, Nov 21, 2011 at 7:43 PM, Paul Wratt wrote:
>> at the moment if you try a recursive wget with --no-clobber
>> --convert-links the --no-clo
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 dir
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 impact
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
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, w
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" :
> From: "Paul Wratt"
>
> > this may have something to do with "working directory" which when an
> > exe is run from a shortcut, u
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 wrote:
> On Wed, Nov 9, 2011 at 23:24, Andrew Daviel wrote:
>> When
On Wed, Nov 9, 2011 at 23: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 dominated by the
> round-trip time for TCP handshakes.
Which is why large files should be stored on FTP servers, not htt
the result of this is --force-clobber is used
On Mon, Nov 21, 2011 at 7:43 PM, Paul Wratt 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 applies to files name
2011/11/29 Andrew Daviel :
> 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.
>
> http://en.wikipedia.org/wiki/Downloa
From: "Paul Wratt"
> 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..
>
another command line option possibly?
Paul
2011/11/30 Andrew Daviel :
> 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
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
From: "Zachariah Yoder"
> 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. Could you a
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
21 matches
Mail list logo