Day of the week and yesterday's date revisited
Timo Salmi
alternatives to the said items. The gawk solutions already there are
neater, but cscript is inherently available for command line
solutions. So I decided on at least some modest vsh exposure for the
pending update of ftp://garbo.uwasa.fi/pc/link/tscmd.zip
The oputline technique used is in fact very familiar all the way
back from pure MS-DOS batch and QBASIC.EXE.
13) How do I get the current day of the week?
@echo off & setlocal enableextensions
:: Build a Visual Basic Script
findstr "'WSH" "%~f0"|findstr /v "findstr" > tmp$$$.vbs
:: Run it with Microsoft Windows Script Host Version 5.6
cscript //nologo tmp$$$.vbs
:: Call the command line script the script host built
call tmp$$$.cmd
:: Clean up
for %%f in (tmp$$$.vbs tmp$$$.cmd) do if exist %%f del %%f
:: Show the result
echo wd_=%wd_%
endlocal & goto :EOF
'
'The Visual Basic Script
Const ForReading = 1, ForWriting = 2, ForAppending = 8 'WSH
Dim DateNow, fso, f 'WSH
DateNow = Date 'WSH
rem WScript.Echo "@set wd_=" & WeekDayName(Weekday(DateNow),true) 'WSH
Set fso = CreateObject("Scripting.FileSystemObject") 'WSH
Set f = fso.OpenTextFile("tmp$$$.cmd", ForWriting, True) 'WSH
f.Write "@set wd_=" & WeekDayName(Weekday(DateNow),true) 'WSH
f.Close 'WSH
6) How does one get yesterday's date?
The problem can also be solved with a Visual Basic Script
@echo off & setlocal enableextensions
:: Build a Visual Basic Script
findstr "'WSH" "%~f0"|findstr /v "findstr" > tmp$$$.vbs
:: Run it with Microsoft Windows Script Host Version 5.6
cscript //nologo tmp$$$.vbs
:: Call the command line script the script host built
call tmp$$$.cmd
:: Clean up
for %%f in (tmp$$$.vbs tmp$$$.cmd) do if exist %%f del %%f
:: Show the result
echo %date%
echo yd_=%yd_%
endlocal & goto :EOF
'
Dim oShell 'WSH
Set oShell = WScript.CreateObject ("WSCript.shell") 'WSH
oShell.run "cmd /c echo @set yd_=" & DateAdd("d",-1,Date) & " > tmp$$$.cmd" 'WSH
The output would be something like
D:\TEST>cmdfaq
31.01.2004
yd_=30.01.2004
All the best, Timo
--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/> ; FIN-65101, Finland
Useful script files and tricks ftp://garbo.uwasa.fi/pc/link/tscmd.zip
Al Dunbar
"Timo Salmi" <t...@UWasa.Fi> wrote in message
news:bvfnop$t...@poiju.uwasa.fi...
> Included somewhat makeshift drafts to add a Visual Basic solution
> alternatives to the said items. The gawk solutions already there are
> neater, but cscript is inherently available for command line
> solutions. So I decided on at least some modest vsh exposure for the
> pending update of ftp://garbo.uwasa.fi/pc/link/tscmd.zip
>
> The oputline technique used is in fact very familiar all the way
> back from pure MS-DOS batch and QBASIC.EXE.
I don't want to start another argument about this type of approach being
something other than a "batch" or "pure batch" solution. In fact, I
appreciate and admire the attributes that allow someone to create such
solutions. But...
If I were writing a script in batch that had so many challenges that I was
forced to revert to an alternative language such as vbscript, I would
probably switch to a vbscript-only solution. The reasons?
- no need to develop the code to communicate between the two platforms.
- difficult to debug vbscript code created on the fly by the batch code.
- simpler to debug a script in a single language that split between two.
Further, if I am going to code in a much more robust language like vbscript,
I don't like it harnessed to the weaker batch language.Even in your
otherwise interesting example below, this tends to create an environment
where exceptions are inevitable, mainly because it is awkward to avoid this
in batch. See comments below:
> 13) How do I get the current day of the week?
>
> @echo off & setlocal enableextensions
> :: Build a Visual Basic Script
> findstr "'WSH" "%~f0"|findstr /v "findstr" > tmp$$$.vbs
Where is file tmp$$$.vbs located? Will it always be available from the batch
script without an explicit path, even if the CD command is used?
Are we guaranteed that the current drive/path will always be writeable by
the current user?
> :: Run it with Microsoft Windows Script Host Version 5.6
> cscript //nologo tmp$$$.vbs
> :: Call the command line script the script host built
> call tmp$$$.cmd
same questions here as noted above for the .vbs file.
> :: Clean up
> for %%f in (tmp$$$.vbs tmp$$$.cmd) do if exist %%f del %%f
Yes, in batch, the names of temporary files are often hard-coded. Sometimes
with problematic results.
> :: Show the result
> echo wd_=%wd_%
> endlocal & goto :EOF
> '
> 'The Visual Basic Script
> Const ForReading = 1, ForWriting = 2, ForAppending = 8 'WSH
> Dim DateNow, fso, f 'WSH
> DateNow = Date 'WSH
> rem WScript.Echo "@set wd_=" & WeekDayName(Weekday(DateNow),true) 'WSH
> Set fso = CreateObject("Scripting.FileSystemObject") 'WSH
> Set f = fso.OpenTextFile("tmp$$$.cmd", ForWriting, True) 'WSH
> f.Write "@set wd_=" & WeekDayName(Weekday(DateNow),true) 'WSH
> f.Close 'WSH
The technique is very interesting on an academic level, where, for example,
a script has exactly one fairly straightforward function to perform. In that
environment, the shortcomings I note above are also academic, as the script
works.
But when one develops more significant scripts, and hopes to do so for
re-usability, this type of approach requires more in the way of code
self-management.
/Al
Marco Maier Said
> If I were writing a script in batch that had so many challenges that I was
> forced to revert to an alternative language such as vbscript, I would
> probably switch to a vbscript-only solution. The reasons?
I think that he is correct in considering a batch-vbscript solution,
in fact there are many situations in which the shortest script is
achieved integrating some command lines with vbscript functions.
Consider for example a script that deletes yesterday's files
with the extensions:
*.tmp,*.~*, ~*.*, *.*~, *.---, *._mp,*.old,*.bak,*.syd,*.chk,*.gid,*.dmp
--
Marco
Timo Salmi
> > alternatives to the said items. The gawk solutions already there are
> > neater, but cscript is inherently available for command line
> I don't want to start another argument about this type of approach being
> something other than a "batch" or "pure batch" solution. In fact, I
Don't worry. As you might have noticed I have recently mostly just
walked away from such goadings (no, not from you), especially after
a certain very sobering reminder. Besides, while it may be relevant
from the point view of what belongs to a newsgroup (often a highly
contested matter), I and I alone decide what goes into my FAQ.
(Please don't get my tone wrong. I am being friendly but at the same
time factual.)
> If I were writing a script in batch that had so many challenges that I was
> forced to revert to an alternative language such as vbscript, I would
> probably switch to a vbscript-only solution. The reasons?
Just like I often solve some of my more complicated own problems
with Turbo Pascal, since I am reasonably comfortable with it. It so
much depends.
> - no need to develop the code to communicate between the two platforms.
> - difficult to debug vbscript code created on the fly by the batch code.
> - simpler to debug a script in a single language that split between two.
All those are good, relevant points. The reason why I included the
options was simply to show that some snippets can be solved that
way, while still being CMD scripting. I do not intend to make VBS
very intensive. If I did, I would choose the newsgroup differently
(VBS) and start a different FAQ. That is not currently in my plans.
> Further, if I am going to code in a much more robust language like vbscript,
> I don't like it harnessed to the weaker batch language.Even in your
> > 13) How do I get the current day of the week?
> > findstr "'WSH" "%~f0"|findstr /v "findstr" > tmp$$$.vbs
> Where is file tmp$$$.vbs located? Will it always be available from the batch
> script without an explicit path, even if the CD command is used?
Such details are the user's worry (and somewhat covered elsewhere in
the FAQ). I included now the general technique. These are not all
ready-to-run utilities but examples of how one gets started with
some of the recurring tasks.
> Are we guaranteed that the current drive/path will always be writeable by
> the current user?
In some other items %temp%\ is utilized. That's how it usually is done.
> The technique is very interesting on an academic level, where, for example,
> a script has exactly one fairly straightforward function to perform. In that
> environment, the shortcomings I note above are also academic, as the script
> works.
Exactly.
> But when one develops more significant scripts, and hopes to do so for
> re-usability, this type of approach requires more in the way of code
> self-management.
Yes, and when one does that, one typically looks at help files and
FAQs to recall some of the syntax details and such. But building up
the application is the user's task. Also bear in mind that even the
very name of my FAQ is "Useful NT/2000/XP script tricks and tips",
which indicates its nature.
But overall, Al, we see the situation in very similar, if not even
equivalent ways.
All the best, Timo
--
Prof. Timo Salmi ftp & http://garbo.uwasa.fi/ archives 193.166.120.5
Department of Accounting and Business Finance ; University of Vaasa
mailto:t...@uwasa.fi <http://www.uwasa.fi/~ts/> ; FIN-65101, Finland
Timo's FAQ materials at http://www.uwasa.fi/~ts/http/tsfaq.html
Dr John Stockton
news:alt.msdos.batch.nt, Timo Salmi <t...@UWasa.Fi> posted at Sat, 31 Jan
2004 10:07:53 :-
> oShell.run "cmd /c echo @set yd_=" & DateAdd("d",-1,Date) & " > tmp$$$.cmd"
Do you see any advantage in DateAdd( ... ) over a simple Date-1 ?
<URL:http://www.merlyn.demon.co.uk/vb-dates.htm> has some date
algorithms in VBscript.
>The output would be something like
> D:\TEST>cmdfaq
> 31.01.2004
So Finland is still not embracing ISO-8601, alas !
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm vb-dates.htm pas-time.htm critdate.htm etc.
Al Dunbar
"Marco Maier Said" <full...@yahoo.it> wrote in message
news:1p2wc8ga...@MRC.MIR.SID.75...
> Al Dunbar wrote in message <news:aHTSb.343141$JQ1.48481@pd7tw1no> :
>
>
> > If I were writing a script in batch that had so many challenges that I
was
> > forced to revert to an alternative language such as vbscript, I would
> > probably switch to a vbscript-only solution. The reasons?
>
> I think that he is correct in considering a batch-vbscript solution,
I wasn't saying he was wrong, just pointing out some factors that might not
occur to casual readers.
> in fact there are many situations in which the shortest script is
> achieved integrating some command lines with vbscript functions.
Ah, shortness! One of my favourite factors - but not the only one.
Simplicity is another desirable factor. And while short and simple often go
hand in hand, shortEST and simple often do not.
> Consider for example a script that deletes yesterday's files
> with the extensions:
> *.tmp,*.~*, ~*.*, *.*~, *.---, *._mp,*.old,*.bak,*.syd,*.chk,*.gid,*.dmp
Sorry, but I missed (or forgot) that particular one - no doubt it was short.
Batch scripts are admittedly typically shorter than the equivalent
vbscripts, and often easier to cobble together for simple file management
tasks. This is because it can just do things (like delete files) without
having to go through the overhead of creating objects.
Batch scripts with embedded vbscript may also be "shorter", but that does
not make that approach the simplest for a number of reasons, some of which I
already gave in my previous reply. They are, in fact, ingenious, and I
appreciate them as such. But anything that requires that level of ingenuity
is most likely not "simple" from the point of view of the casual reader.
What do you see as the advantage of shortness:
- quick to type (but difficult to get it right)
- quick to run (not necessarily)
- portable (not really much difference between a 100 byte batch file and a
5K one on that score)
/Al
Michael Bednarek
Given the right CLI, with a single command:
DEL /[d-1] *.tmp;*.~*;~*.*;*.*~;*.---;*._mp;*.old;*.bak;*.syd;*.chk;*.gid;*.dmp
Timo Salmi
> Timo Salmi <t...@UWasa.Fi> posted at Sat, 31 Jan 2004 10:07:53 :
> Do you see any advantage in DateAdd( ... ) over a simple Date-1 ?
John, it is just my plain ignorance. You see, while I have gathered
over the decades some modest amount of experience in programming and
more lately in combining batches/scripts with additional tools, I am
not familiar with the details of VBScripts. I actually wrote my very
first VBS lines only yesterday after locating, downloading and
installing the extensive "Microsoft Windows Script Technologies"
help file scrdoc56en.exe from Microsoft's server. On the other hand,
the very best moment for FAQ writing is at the beginning of one's
learning curve. Later one may take some things too much for granted.
> <URL:http://www.merlyn.demon.co.uk/vb-dates.htm> has some date
> algorithms in VBscript.
Good. I am including into the FAQ a Google reference to your
posting.
> >The output would be something like
> > D:\TEST>cmdfaq
> > 31.01.2004
> So Finland is still not embracing ISO-8601, alas !
While a side issue from the point of view of scripting, there are
only two logical formats, conventions aside. That one and
2004.01.31, for very obvious reasons. Furthermore, I'd like to make
the same comment as to good Al. That is that for serious script
writing one has to go through and customize one's code. A FAQ is
just a FAQ with snippets that hopefully are useful for the true-life
serious tasks. (I know that they are since some items are parts of
my own production runs.) Therefore, I do not worry overly much about
the potential volatility of some of the facets.
Marco Maier Said
> What do you see as the advantage of shortness:
>
> - quick to type (but difficult to get it right)
> - quick to run (not necessarily)
> - portable (not really much difference between a 100 byte batch file and a
> 5K one on that score)
>
> /Al
There are two advantages: they are quick to create and nice to see.
--
Marco
Marco Maier Said
<news:ojlo1094agh3ahg41...@4ax.com> :
> Given the right CLI, with a single command:
> DEL /[d-1] *.tmp;*.~*;~*.*;*.*~;*.---;*._mp;*.old;*.bak;*.syd;*.chk;*.gid;*.dmp
??
Michael Bednarek
wrote in alt.msdos.batch.nt:
>Michael Bednarek wrote in message
I'm not sure what the subject of your question marks is.
If you query what the question to my answer is: it's your own post:
On Sat, 31 Jan 2004 20:30:27 GMT, Marco Maier Said <full...@yahoo.it>
wrote in alt.msdos.batch.nt:
[snip]
>I think that he is correct in considering a batch-vbscript solution,
>in fact there are many situations in which the shortest script is
>achieved integrating some command lines with vbscript functions.
>Consider for example a script that deletes yesterday's files
>with the extensions:
>*.tmp,*.~*, ~*.*, *.*~, *.---, *._mp,*.old,*.bak,*.syd,*.chk,*.gid,*.dmp
Surely, the quoted command is hard to beat on shortness.
If your question regards which CLI will execute the command, it's 4NT
and its DEL command is documented at <http://jpsoft.com/help/del.htm>,
date ranges at <http://jpsoft.com/help/dateranges.htm>, filename include
lists at <http://jpsoft.com/help/incllist.htm>.
--
Michael Bednarek http://mbednarek.com/ "POST NO BILLS"
Marco Maier Said
>
> If your question regards which CLI will execute the command, it's 4NT
> and its DEL command is documented at <http://jpsoft.com/help/del.htm>,
> date ranges at <http://jpsoft.com/help/dateranges.htm>, filename include
> lists at <http://jpsoft.com/help/incllist.htm>.
Ah OK, but,sincerely,I'm only interested in
built-in solutions
Best
Al Dunbar
Nice to see I will grant you. But quick to create? That rather depends on
the individual doing the creating. I have no doubt that that approach would
perhaps be the quickest for you to code, given your penchant for doing it
this way.
While I haven't done any timing tests on my own relative speed with the
technique as compared with a fully vbscript solution, I would suggest that I
would lean towards the (simpler and easier to debug) approach of doing it
all in vbscript. In fact, much of the small project vbscript only code I
have written was also "quick to create and nice to see".
The question as to the relative speed of *you* coding a short script in your
inimitable batch/vbscript way and my doing it in just vbscript might be an
interesting concept. But when it comes to promoting various techniques to
others, it would be a totally meaningless metric.
/Al
Al Dunbar
"Timo Salmi" <t...@UWasa.Fi> wrote in message
> Dr John Stockton <sp...@merlyn.demon.co.uk> wrote:
> > Timo Salmi <t...@UWasa.Fi> posted at Sat, 31 Jan 2004 10:07:53 :
> > > oShell.run "cmd /c echo @set yd_=" & DateAdd("d",-1,Date) & " >
tmp$$$.cmd"
<snip>
> > >The output would be something like
> > > D:\TEST>cmdfaq
> > > 31.01.2004
> > So Finland is still not embracing ISO-8601, alas !
>
> While a side issue from the point of view of scripting, there are
> only two logical formats, conventions aside. That one and
> 2004.01.31, for very obvious reasons.
I disagree. 2004-01-31 is superior to 2004.01.31 (at least in programming
circles) for the obvious reason that one sometimes might specify a
particular month by leaving off the day field. This leaves two numeric
fields and a single field delimiter. Suppose the month in question were next
November, and one were to read the date in to a variable in, say, vbscript:
if the month was given as 2004-10, the variable would be a string containing
"2004-10"
if the month was given as 2004.10, the variable would be a real number equal
to 2004.1
> Furthermore, I'd like to make
> the same comment as to good Al. That is that for serious script
> writing one has to go through and customize one's code. A FAQ is
> just a FAQ with snippets that hopefully are useful for the true-life
> serious tasks. (I know that they are since some items are parts of
> my own production runs.) Therefore, I do not worry overly much about
> the potential volatility of some of the facets.
Quite, and I agree. In fact, if your FAQ was so exactingly correct as to not
result in any disagreement (and therefore discussion), that would perhaps be
a bad thing. As it is, people looking for a quick fix method for something
that eludes them benefit from the FAQ, and perhaps also from the ensuing
discussion that results.
/Al
Timo Salmi
> > 2004.01.31, for very obvious reasons.
> I disagree. 2004-01-31 is superior to 2004.01.31 (at least in programming
> circles) for the obvious reason that one sometimes might specify a
> if the month was given as 2004-10, the variable would be a string containing
> "2004-10"
Or a real numer 1994 :-)
> if the month was given as 2004.10, the variable would be a real number equal
> to 2004.1
Indeed.
Anyway, the location of the year, month, day fields is more crucial
that the particular separator (typically . / or - ).
Dr John Stockton
news:alt.msdos.batch.nt, Al Dunbar <alan-no-...@hotmail.com>
posted at Sun, 1 Feb 2004 16:56:03 :-
>
>"Timo Salmi" <t...@UWasa.Fi> wrote in message
>news:bvibde$r...@poiju.uwasa.fi...
>> Dr John Stockton <sp...@merlyn.demon.co.uk> wrote:
>> > Timo Salmi <t...@UWasa.Fi> posted at Sat, 31 Jan 2004 10:07:53 :
>> > > oShell.run "cmd /c echo @set yd_=" & DateAdd("d",-1,Date) & " >
>tmp$$$.cmd"
>
><snip>
>
>> > >The output would be something like
>> > > D:\TEST>cmdfaq
>> > > 31.01.2004
>> > So Finland is still not embracing ISO-8601, alas !
>>
>> While a side issue from the point of view of scripting, there are
>> only two logical formats, conventions aside. That one and
>> 2004.01.31, for very obvious reasons.
>
>I disagree. 2004-01-31 is superior to 2004.01.31 (at least in programming
>circles) for the obvious reason that one sometimes might specify a
>particular month by leaving off the day field. This leaves two numeric
>fields and a single field delimiter. Suppose the month in question were next
>November, and one were to read the date in to a variable in, say, vbscript:
>
>if the month was given as 2004-10, the variable would be a string containing
>"2004-10"
>
>if the month was given as 2004.10, the variable would be a real number equal
>to 2004.1
One should use 2004-01-31 because it is an ISO standard (8601) and, once
understood to be a Gregorian date, cannot reasonably be misinterpreted.
That standard is also a European Norm, and is a national standard in
many countries (for example, AIUI, USA Standard: ANSI X3.30-1985(R1991),
FIPS PUB 4-1, 4-2).
However, that apart, 2004.01.31 has the advantage that, unlike forms
using - or /, it cannot be read as a valid numeric expression.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
Al Dunbar
"Timo Salmi" <t...@UWasa.Fi> wrote in message
> Al Dunbar <alan-no-...@hotmail.com> wrote:
> > "Timo Salmi" <t...@UWasa.Fi> wrote in message
> > > only two logical formats, conventions aside. That one and
> > > 2004.01.31, for very obvious reasons.
>
> > I disagree. 2004-01-31 is superior to 2004.01.31 (at least in
programming
> > circles) for the obvious reason that one sometimes might specify a
>
> > if the month was given as 2004-10, the variable would be a string
containing
> > "2004-10"
>
> Or a real numer 1994 :-)
I hadn't thought of that ;-) I was thinking in terms of a specific language
in which input values are parsed simply to determine the data type.
Including a mathematical expression such as that would result in the input
being interpretted as a string.
> > if the month was given as 2004.10, the variable would be a real number
equal
> > to 2004.1
>
> Indeed.
>
> Anyway, the location of the year, month, day fields is more crucial
> that the particular separator (typically . / or - ).
I agree.
But, less crucially, the "-" is still somewhat less objectionable overall
when compared with the other two delimiters when it comes to application.
Consider trying to create a file called "2004/02/02.txt" compared with, say
"2004-02-02.txt". Of course, one *could* create a file called
"2004.02.02.txt". Unfortunately historical bias is such that this could
result in ambiguities for some software.
/Al
Al Dunbar
"Dr John Stockton" <sp...@merlyn.demon.co.uk> wrote in message
news:D5wsSmN2...@merlyn.demon.co.uk...
Aside from my rationalizations which simply indicate that I think this
standard was particularly well chosen, remaining ISO compliant is certainly
a good reason to use the "-".
> and, once
> understood to be a Gregorian date, cannot reasonably be misinterpreted.
> That standard is also a European Norm, and is a national standard in
> many countries (for example, AIUI, USA Standard: ANSI X3.30-1985(R1991),
> FIPS PUB 4-1, 4-2).
Yet more valid reasons to comply...
> However, that apart, 2004.01.31 has the advantage that, unlike forms
> using - or /, it cannot be read as a valid numeric expression.
Doesn't even make a good IP address!
But I suspect that the ISO 8601 team had more practical matters in mind than
how the various formats might be misinterpretted by software, namely
avoiding real and actual ambiguity of dates that use any of the previously
common date formats. I still find it hard to believe that we didn't all just
universally start using yyyy-mm-dd shortly before 2000 on the realization
that not doing so would cause problems. Given the fact that some entities
refuse to change, then, perhaps 8601 was necessary.
As far as date formats being misinterpretted by software, though,
date-related software shouldn't be bothered by that kind of ambiguity; it
should just be coded correctly.
/Al
Timo Salmi
> Consider trying to create a file called "2004/02/02.txt" compared with, say
> "2004-02-02.txt". Of course, one *could* create a file called
> "2004.02.02.txt". Unfortunately historical bias is such that this could
> result in ambiguities for some software.
Again, agreed. That's why in my FAQ the date constituents are
obtained into separate environment variables in the relevant FAQ
items. Which combined makes for eg. 20040203
Timo Salmi
> "Dr John Stockton" <sp...@merlyn.demon.co.uk> wrote in message
> > >> > So Finland is still not embracing ISO-8601, alas !
> > many countries (for example, AIUI, USA Standard: ANSI X3.30-1985(R1991),
> > FIPS PUB 4-1, 4-2).
> Yet more valid reasons to comply...
I do not disgaree. However, we all have a slight, computer centered
mindset bias in this. Not everything, even in the official life, is
about computer standards. Besides, I'll take this far more seriously
after US goes metric and the UK drops the rest of its non-metric
remnants. :-)
Matthias Tacke
<snip>
>Besides, I'll take this far more seriously after US goes metric and
>the UK drops the rest of its non-metric remnants. :-)
>
--
Greetings
Matthias________________________________________
For help on nt commands enter in a cmd window:
W2K>HH windows.chm::ntcmds.htm XP>HH ntcmds.chm
Al Dunbar
"Matthias Tacke" <Matt...@Tacke.de> wrote in message
news:bvo8b3$g2$02$1...@news.t-online.com...
> Timo Salmi wrote:
> <snip>
> >Besides, I'll take this far more seriously after US goes metric and
> >the UK drops the rest of its non-metric remnants. :-)
> >
> How old do I have to grow, to be still alive if this happens? :-)
LOL! I haven't heard anything lately to even suggest a metric US is even
considered a possibility at any point in the future.
/Al
Gary Smith
> Timo Salmi wrote:
> <snip>
>>Besides, I'll take this far more seriously after US goes metric and
>>the UK drops the rest of its non-metric remnants. :-)
>>
> How old do I have to grow, to be still alive if this happens? :-)
It shouldn't be more than another kiloyear or two.
--
Gary L. Smith gls...@yahoo.com
Columbus, Ohio
Al Dunbar
"Gary Smith" <bitb...@example.com> wrote in message
news:102gvec...@corp.supernews.com...
> Matthias Tacke <Matt...@tacke.de> wrote:
> > Timo Salmi wrote:
> > <snip>
> >>Besides, I'll take this far more seriously after US goes metric and
> >>the UK drops the rest of its non-metric remnants. :-)
> >>
> > How old do I have to grow, to be still alive if this happens? :-)
>
> It shouldn't be more than another kiloyear or two.
Hmmmm, what's a kiloyear in non-metric units; ten centuries? 26000
fortnights? fifty score and zero years? a millenium? Or just too darned long
a time for any one person to wait?
/Al