Ian Abbott [EMAIL PROTECTED] writes:
On 5 Apr 2002 at 18:17, Noel Koethe wrote:
Will this be changed so the user could use -nv with /dev/null
and get only errors or warnings displayed?
So what I think you want is for any log message tagged as
LOG_VERBOSE (verbose information) or
On 9 Apr 2002 at 10:34, Hrvoje Niksic wrote:
Ian Abbott [EMAIL PROTECTED] writes:
On 5 Apr 2002 at 18:17, Noel Koethe wrote:
Will this be changed so the user could use -nv with /dev/null
and get only errors or warnings displayed?
So what I think you want is for any log message tagged
Guys
For what its worth:-
Most of my code logs to a level using something like
command --verbose 10 .|| -v10 etc.
In my code, I call a trace routine that simply checks the verbose level
with the call level and log if it is -ge.
EG:-
// in
Justin Piszcz [EMAIL PROTECTED] writes:
--12:12:21-- ftp://war:*password*@0.0.0.0:21//iso/file.iso
= `iso/file.iso'
== CWD not required.
== PASV ... done.== RETR file.iso ... done.
Length: 737,402,880
24% [] 180,231,952 37.40K/s ETA
Torsten Fellhauer -iXpoint- #429 [EMAIL PROTECTED] writes:
when connecting to a FTP-Server using a TrendMicro Viruswall Proxy,
we get the error Malformed status line,
Unfortunately, Wget is right; that status line is quite different from
what HTTP mandates. The status line should be
Matthias Jim Knopf [EMAIL PROTECTED] writes:
there is a bug (or a feature...) in the version 1.5.3
Note that the latest version of Wget is 1.8.1. I suggest you to
upgrade because the new version handles URLs much better.
I discovered that every doubled slash (//) is converted to a single
On Tue, 9 Apr 2002, Hrvoje Niksic wrote:
Instead, the TrendMicro Viruswall Proxy returns:
220 InterScan Version 3.6-Build_1166 $Date: 04/24/2001 22:13:0052$ (mucint01,
dynamic, get: N, put: N): Ready
That is so far from HTTP that even if Wget's parser were lenient it still
wouldn't
Netgain specifics are closed source and proprietrary, however the BST protocol is
open.
Bug in BST/TCP/NetGain, no matter which it is, the rollback option [when used]
appears to fix the problem quite nicely.
Alexander V. Lukyanov wrote:
On Tue, Apr 09, 2002 at 02:55:25PM +0200, Hrvoje Niksic
¾È³çÇϽʴϱî? ÇÁ¸°ÅÍ À×Å©/Åä³Ê Àü¹®¼îÇθô À×Å©·Î´åÄÄ(www.inkro.com)ÀÔ´Ï´Ù.
º» ¸ÞÀÏÀº À¥¼ÇÎÁß ¾Ë°ÔµÇ¾úÀ¸¸ç °í°´´ÔÀÇ À̸ÞÀÏ ÁÖ¼ÒÀÌ¿Ü¿¡ ¾î¶°ÇÑ Á¤º¸µµ °®°íÀÖÁö
On 8 Apr 2002 at 11:43, Urs Thuermann wrote:
Please CC: any answers to my email address, since I'm not on this
list.
I'd like wget to get the time stamp of a file that is downloaded via
FTP and to set the mtime after writing the file to the local disk.
When using HTTP, this already
On 9 Apr 2002 at 16:52, Ian Abbott wrote:
Wget recently adopted use of another extension (SIZE) and has long
supported another extension (REST), so it could potentially adopt
other extensions if commonly used.
Correction: 'REST' is a standard FTP protocol command, not an
extension.
Since I implemented the progress bar, I've progressively become more
and more annoyed by the fact that the download speed it reports is the
average download speed. What I'm usually much more interested in is
the current download speed.
This patch implements this change; the current download
On Tue, 9 Apr 2002, Hrvoje Niksic wrote:
Should we revert to the average speed for ETA, or is there a smarter way to
handle it? What are other downloaders doing?
I'll grab the other part and explain what curl does. It shows a current
speed based on the past five seconds, it shows an average
Hrvoje Niksic wrote:
The one remaining problem is the ETA. Based on the current speed, it
changes value wildly. Of course, over time it is generally
decreasing, but one can hardly follow it. I removed the flushing by
making sure that it's not shown more than once per second, but this
Maurice Cinquini [EMAIL PROTECTED] writes:
I don't think using only a fraction of a second is a reliable method
for estimating current bandwidth. Here are some factors that can
make for a wildly varing ETAs when just looking at the last fraction
of a second.
- TCP slow start.
-
Daniel Stenberg [EMAIL PROTECTED] writes:
On Tue, 9 Apr 2002, Hrvoje Niksic wrote:
Should we revert to the average speed for ETA, or is there a smarter way to
handle it? What are other downloaders doing?
I'll grab the other part and explain what curl does. It shows a current
speed based
Tony Lewis [EMAIL PROTECTED] writes:
I'm often annoyed by ETA estimates that make no sense. How about showing two
values -- something like:
ETA at average speed: 1:05:17
ETA at current speed: 15:05
The problem is that Wget is limited by what fits in one line. I'd
like to keep enough space
Hrvoje Niksic wrote:
I'll grab the other part and explain what curl does. It shows a
current
speed based on the past five seconds,
Does it mean that the speed doesn't change for five seconds, or that
you always show the *current* speed, but relative to the last five
seconds? I may be
Tony Lewis [EMAIL PROTECTED] writes:
Could you keep an array of speeds that is updated once a second such that
the value from six seconds ago is discarded and when the value for the
second that just ended is recorded?
Right now I'm doing that kind of trick, but for the last N reads from
the
Andre Majorel [EMAIL PROTECTED] writes:
If find it very annoying when a downloader plays yoyo with the
remaining time. IMHO, remaining time is by nature a long term thing
and short term jitter should not cause it to go up and down.
Agreed wholeheartedly, but how would you *implement* a
Hi!
I recently managed to get my big machine online using a two PC
(Windows boxes) LAN.
A PI is the server, running both Zonealaram and Jana under Win98.
The first one a firewall, the second one a proxy programme.
On my client, an Athlon 1800+ with Windows 2000
I want to work with wget and
21 matches
Mail list logo
