-=> Paul Quinn wrote to Robert Bull <=-

 PQ> Anyhow.  On with the testing...

 PQ>   [C:\RUBBISH\DELETE]cmdtime --e copy \config.sys .\{at}Q{at}Z.txt{at}Q
 PQ>   Command: copy \config.sys .\"E. Austral_+.txt"
 PQ>           1 file(s) copied

Oh oh!  CMDTIME shouldn't do that.  Looks like it was taking the long time
zone information string from Windows and truncating it.  That will be
corrected right away.

 PQ> Then I set TZ, after reading the doco more closely.[slap! to the
 PQ> forehead]

Even so, the program should be a bit more forgiving than that.

 PQ> Interesting result when TZ wasn't set, hey.  Yikes!  I just spotted the
 PQ> file creation dates; WTF did 18:48 on 6 April come from!?!  I only did
 PQ> the tests about 10 minutes ago.  Mmm... is that one of the problems you
 PQ> had in mind?

Wow, that one has me stumped.  CMDTIME doesn't do anything with file dates
or make changes to the system clock.  All it does is make the specified
substitutions in the command line and pass the revised string to the system
command processor.  It's especially strange, because I can't get the same
thing to happen here.  My first thought was that it had something strange
to do with the TZ setting, but it looks like the same thing happened before
you set the TZ variable.  If you do the same copy instruction from the
command line (without CMDTIME) does the same thing happen?

BTW, there is a new version posted at http://www.rsds.ca/misc.html that
deals much more gracefully with the Windows provided long time zone
information, when there is no TZ environment variable set.

I *may* be able to compile a 16-bit DOS version if there is any interest,
but I don't have any way to test it here.  Any takers?

Thanks for your help.

Bob

-+- blueMail/Linux 1.0

--- BBBS/LiI v4.01 Flag-4