Re: wget -o question

2007-10-01 Thread Steven M. Schweda
From: Micah Cowan

 But, since any specific transaction is unlikely to take such a long
 time, the spread of the run is easily deduced by the start and end
 times, and, in the unlikely event of multiple days, counting time
 regressions.

   And if the pages in books were all numbered 1, 2, 3, 4, 5, 6, 7, 8,
9, 0, 1, 2, 3, ..., the reader could easily deduce the actual number for
any page, but most folks find it more convenient when all the necessary
data are right there in one place.

   But hey.  You're the boss.

   SMS.


Re: wget -o question

2007-10-01 Thread Micah Cowan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Steven M. Schweda wrote:

 But, since any specific transaction is unlikely to take such a long
 time, the spread of the run is easily deduced by the start and end
 times, and, in the unlikely event of multiple days, counting time
 regressions.
 
And if the pages in books were all numbered 1, 2, 3, 4, 5, 6, 7, 8,
 9, 0, 1, 2, 3, ..., the reader could easily deduce the actual number for
 any page, but most folks find it more convenient when all the necessary
 data are right there in one place.

To my mind, books are much more likely to cross 10-page boundaries
several severals of times, than Wget is to cross more than just one
24-hour boundary. And, there's always date; wget; date...

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHAJch7M8hyUobTrERCKMDAKCFxnnZrB0vIrquoMi5x/F+32DlCwCcDWdP
3U+0+vCH1tXGCJ3pk9KR3xM=
=ZDLY
-END PGP SIGNATURE-


Re: wget -o question

2007-10-01 Thread Jim Wright
My usage is counter to your assumptions below.  I run every hour to
connect to 1,000 instruments (1,500 in 12 months) dispersed over the
entire western US and Alaska.  I append log messages for all runs from
a day to a single file.  This is an important debugging tool for us.
We have mostly VSAT and CDMA connections for remote instruments, but many
other variations.  Small bandwidth, large latency, and potentially large
backlogs of data means we can run for a couple days catching up with an
instrument - rare, but it happens.  The current timestamping is a PAIN for
us to automatically parse.  A change as proposed here is very simple, but
would be VERY useful.  Right now, we have 116 gigabytes of wget log files.

Jim


On Sun, 30 Sep 2007, Micah Cowan wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Steven M. Schweda wrote:
  From: Micah Cowan
  
  -  tms = time_str (NULL);
  +  tms = datetime_str (NULL);
  
  Does anyone think there's any general usefulness for this sort of
  thing?
  
 I don't care much, but it seems like a fairly harmless change with
  some benefit.  Of course, I use an OS where a directory listing which
  shows date and time does so using a consistent and constant format,
  independent of the age of a file, so I may be biased.
 
 :)
 
 Though honestly, what this change buys you above simply doing date;
 wget, I don't know. I think maybe I won't bother, at least for now.
 
  Though if I were considering such a change, I'd probably just have wget
  mention the date at the start of its run, rather than repeat it for each
  transaction. Obviously wouldn't be a high-priority change... :)
  
 That sounds reasonable, except for a job which begins shortly before
  midnight.
 
 I considered this, along with the unlikely 24-hour wget run.
 
 But, since any specific transaction is unlikely to take such a long
 time, the spread of the run is easily deduced by the start and end
 times, and, in the unlikely event of multiple days, counting time
 regressions.
 
 - --
 Micah J. Cowan
 Programmer, musician, typesetting enthusiast, gamer...
 http://micah.cowan.name/
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.6 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
 iD8DBQFHAIP67M8hyUobTrERCFFIAJ9Pltuwqr0FeOtlwuFPotKxoBa6TgCeKb2l
 dtRfakFDQ47qcUJJFKXPVwY=
 =t50d
 -END PGP SIGNATURE-
 


Re: wget -o question

2007-10-01 Thread Micah Cowan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jim Wright wrote:
 My usage is counter to your assumptions below.[...]
 A change as proposed here is very simple, but
 would be VERY useful.

Okay. Guess I'm sold, then. :D

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHAKcq7M8hyUobTrERCCxhAKCPbzNRHGkVbZTcaEBlI7xNqroJbACeKSYO
kdixUTJro4Pp3CszOYdjfHE=
=NaSh
-END PGP SIGNATURE-


Re: wget -o question

2007-10-01 Thread Saso Tomat
Micah Cowan micah at cowan.name writes:

 
 
 Jim Wright wrote:
  My usage is counter to your assumptions below.[...]
  A change as proposed here is very simple, but
  would be VERY useful.
 
 Okay. Guess I'm sold, then. :D
 
 --
 Micah J. Cowan
 Programmer, musician, typesetting enthusiast, gamer...
 http://micah.cowan.name/
 
 


Thank you all for your replies. Yes, it is very needed. I use wget on WIN OS. 
I have a .cmd file that performs wget for several days/weeks/months if needed 
so the date information is very usefull.

Thank you.
Saso



Re: wget -o question

2007-09-30 Thread Steven M. Schweda
From: Micah Cowan

  -  tms = time_str (NULL);
  +  tms = datetime_str (NULL);

 Does anyone think there's any general usefulness for this sort of
 thing?

   I don't care much, but it seems like a fairly harmless change with
some benefit.  Of course, I use an OS where a directory listing which
shows date and time does so using a consistent and constant format,
independent of the age of a file, so I may be biased.

 Though if I were considering such a change, I'd probably just have wget
 mention the date at the start of its run, rather than repeat it for each
 transaction. Obviously wouldn't be a high-priority change... :)

   That sounds reasonable, except for a job which begins shortly before
midnight.  I'd say that it makes more sense to do it the same way every
time.  Otherwise, why bother displaying the hour every time, when it
changes so seldom?  Or the minute?  Eleven bytes more per file in the
log doesn't seem to me to be a big price to pay for consistent
simplicity.  Or you could let the victim specify a strptime() format
string, and satisfy everyone.  Personally, I'd just change time_str() to
datetime_str() in a couple of places.



   Steven M. Schweda   [EMAIL PROTECTED]
   382 South Warwick Street(+1) 651-699-9818
   Saint Paul  MN  55105-2547


Re: wget -o question

2007-09-30 Thread Micah Cowan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Steven M. Schweda wrote:
 From: Micah Cowan
 
 -  tms = time_str (NULL);
 +  tms = datetime_str (NULL);
 
 Does anyone think there's any general usefulness for this sort of
 thing?
 
I don't care much, but it seems like a fairly harmless change with
 some benefit.  Of course, I use an OS where a directory listing which
 shows date and time does so using a consistent and constant format,
 independent of the age of a file, so I may be biased.

:)

Though honestly, what this change buys you above simply doing date;
wget, I don't know. I think maybe I won't bother, at least for now.

 Though if I were considering such a change, I'd probably just have wget
 mention the date at the start of its run, rather than repeat it for each
 transaction. Obviously wouldn't be a high-priority change... :)
 
That sounds reasonable, except for a job which begins shortly before
 midnight.

I considered this, along with the unlikely 24-hour wget run.

But, since any specific transaction is unlikely to take such a long
time, the spread of the run is easily deduced by the start and end
times, and, in the unlikely event of multiple days, counting time
regressions.

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHAIP67M8hyUobTrERCFFIAJ9Pltuwqr0FeOtlwuFPotKxoBa6TgCeKb2l
dtRfakFDQ47qcUJJFKXPVwY=
=t50d
-END PGP SIGNATURE-