tscmd43.zip Useful NT/2000/XP script tricks and tips
Timo Salmi
192436 Feb 14 2007 ftp://garbo.uwasa.fi/pc/link/tscmd.zip
tscmd43.zip Useful NT/2000/XP script tricks and tips, T.Salmi
Added the scripts
DATET.CMD Put the current date parts into the environment
(Aka the mother of all command-line script FAQs)
FINDTMP.CMD Find and list all the *.TMP files
(Mainly a demo of another top FAQ)
RULER.BAT An aid to pinpoint CLI screen colums and rows
TSCD.CMD Show current/given folder both in short and long formats
WHOISME.CMD Get IP and user information
Added the following FAQ item to 1CMDFAQ.TXT
158} Why won't the statements within my if condition work properly?
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
Todd Vargo
Timo Salmi wrote:
> Wed 14-Feb-2007: I have made an update
>
> 192436 Feb 14 2007 ftp://garbo.uwasa.fi/pc/link/tscmd.zip
> tscmd43.zip Useful NT/2000/XP script tricks and tips, T.Salmi
>
> Added the scripts
> DATET.CMD Put the current date parts into the environment
> (Aka the mother of all command-line script FAQs)
@set DatetDD=2/
@set DatetMM=4/
@set DatetYY=
@set DatetYYYY=7
@set DatetWkD=Wed
@set DatetMon=Feb
@set DatetHH=13
@set DatetMI=56
@set DatetSS=12
DATET.CMD uses haphazard locale specific extraction for date parts. With as
much discussion as Date/Time locale has received over the years, I would
expect Day(), Month() and Year(), VBS functions used.
Wscript.Echo "@set DatetDD=" & Right(0 & Day(DateNow), 2) 'VBS
Wscript.Echo "@set DatetMM=" & Right(0 & Month(DateNow), 2) 'VBS
Wscript.Echo "@set DatetYY=" & Right(Year(DateNow), 2) 'VBS
Wscript.Echo "@set DatetYYYY=" & Year(DateNow) 'VBS
Other features of tscmd.zip not evaluated at this time.
--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)
Timo Salmi
>> DATET.CMD Put the current date parts into the environment
> DATET.CMD uses haphazard locale specific extraction for date parts. With as
> much discussion as Date/Time locale has received over the years, I would
> expect Day(), Month() and Year(), VBS functions used.
Thank you for catching that.
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
Timo Salmi
> Todd Vargo wrote:
>>> DATET.CMD Put the current date parts into the environment
>> years, I would expect Day(), Month() and Year(), VBS functions
>> used.
> Thank you for catching that.
It is probably of little or no interest to others but me as the author
where my oversight came from, because in the actual FAQ, the
1CMDFAQ.TXT, I have used those functions and sometimes the DatePart
function. Anyway, I traced my blunder back to EDATE.CMD first written
some while ago. I had copied and pasted parts from there. Subsequently,
I have tried to correct both EDATE.CMD and DATET.CMD in the collection
and uploaded the corrected version to Garbo.
Not the first, nor the last, error I make and get corrected by the
readership for common good. I can only hope that I got it right now. But
testing different locales from a single one is guesswork at best and
waiting for observations from the others.
Matthias Tacke
> I have tried to correct both EDATE.CMD and DATET.CMD in the collection
> and uploaded the corrected version to Garbo.
>
still no success with my German locale. Mainly because my temp path
contains spaces and you don't quote the file names.
HTH
Matthias
Timo Salmi
> Timo Salmi schrieb:
>> I have tried to correct both EDATE.CMD and DATET.CMD in the
>> collection and uploaded the corrected version to Garbo.
> still no success with my German locale. Mainly because my temp path
> contains spaces and you don't quote the file names.
That is a different kind of a problem and on a different level. In
general, it is bad practice to use anything but the stort format in
defining one's TEMP and TMP paths. This is the first time I've heard of
someone using such a practice. But you are right. I'll correct that
oddity for the next version in due time. Thank you for pointing out also
that eventuality. This is the kind of a quality control that's very
useful, and much appreciated.
Timo Salmi
> Matthias Tacke <Matt...@Tacke.de> wrote:
>> still no success with my German locale. Mainly because my temp path
>> contains spaces and you don't quote the file names.
> That is a different kind of a problem and on a different level. In
> general, it is bad practice to use anything but the stort format in
> defining one's TEMP and TMP paths. This is the first time I've heard of
> someone using such a practice.
Matthias, if indeed you have such a practice, it might be useful to
consider the following kind of line high up in or before all your
scripts:
for /f "tokens=*" %%f in ("%temp%") do set temp=%%~sf
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
Matthias Tacke
> Matthias Tacke <Matt...@Tacke.de> wrote:
>> Timo Salmi schrieb:
>> contains spaces and you don't quote the file names.
>
> That is a different kind of a problem and on a different level. In
> general, it is bad practice to use anything but the stort format in
> defining one's TEMP and TMP paths.
I didn't change the temp path. Due to right issues xp places the path
in %USERPROFILE%\local settings\Temp.
Since the userprofile usually is "documents and settings\username" or a
localized version "Dokumente und Einstellungen" you get the unwanted
spaces.
--
Greetings
Matthias
Timo Salmi
> I didn't change the temp path. Due to right issues xp places the path
> in %USERPROFILE%\local settings\Temp.
Fortunately, as I wrote, one can sidestep that problem by getting the
short format of that path. Either changing the actual TEMP and TMP if
the rights allow. And if not, setting a temp_ environment variable and
using that instead in the scripts
for /f "tokens=*" %%f in ("%temp%") do set temp_=%%~sf
It is quite conceivable that many scripts on the net, not just mine, get
broken with the unexpected long-named TEMP versions.
The problem with DATET.CMD that Todd brought up, that is totally on me.
But the TEMP long path dilemma is an anomaly that's not just on my tab.
Nevertheless, I have corrected it for the eventuality for the
next release. But inserting the kind of a line above should get you
going, especially with the high level of script knowledge that you posses.
Al Dunbar
"Timo Salmi" <t...@uwasa.fi> wrote in message
news:45d3b1bf$0$24598$9b53...@news.fv.fi...
> Matthias Tacke <Matt...@Tacke.de> wrote:
> > I didn't change the temp path. Due to right issues xp places the path
> > in %USERPROFILE%\local settings\Temp.
>
> Fortunately, as I wrote, one can sidestep that problem by getting the
> short format of that path. Either changing the actual TEMP and TMP if
> the rights allow. And if not, setting a temp_ environment variable and
> using that instead in the scripts
>
> for /f "tokens=*" %%f in ("%temp%") do set temp_=%%~sf
>
> It is quite conceivable that many scripts on the net, not just mine, get
> broken with the unexpected long-named TEMP versions.
>
> The problem with DATET.CMD that Todd brought up, that is totally on me.
> But the TEMP long path dilemma is an anomaly that's not just on my tab.
> Nevertheless, I have corrected it for the eventuality for the
> next release. But inserting the kind of a line above should get you
> going, especially with the high level of script knowledge that you posses.
>
> All the best, Timo
My two cents on the issue: maybe NTFS (and windows) should be re-engineered
to remove long filenames in favour of 8.3 names because we are having so
much trouble with them!
Or, alternately, perhaps we should start properly considering the general
case when it comes to filenames. It seems a little sideways to me to use
tools that do not do this for us, but require us to convert any potentially
long filename to short format just for the convenience of the tool.
/Al
foxidrive
>Matthias Tacke <Matt...@Tacke.de> wrote:
>> I didn't change the temp path. Due to right issues xp places the path
>> in %USERPROFILE%\local settings\Temp.
>
>Fortunately, as I wrote, one can sidestep that problem by getting the
>short format of that path. Either changing the actual TEMP and TMP if
>the rights allow. And if not, setting a temp_ environment variable and
>using that instead in the scripts
>
> for /f "tokens=*" %%f in ("%temp%") do set temp_=%%~sf
>
>It is quite conceivable that many scripts on the net, not just mine, get
>broken with the unexpected long-named TEMP versions.
Thank Microsoft. It's been standard behaviour for many years.
Todd Vargo
> Matthias Tacke <Matt...@Tacke.de> wrote:
> > I didn't change the temp path. Due to right issues xp places the path
> > in %USERPROFILE%\local settings\Temp.
>
> Fortunately, as I wrote, one can sidestep that problem by getting the
> short format of that path. Either changing the actual TEMP and TMP if
> the rights allow. And if not, setting a temp_ environment variable and
> using that instead in the scripts
>
> for /f "tokens=*" %%f in ("%temp%") do set temp_=%%~sf
>
> It is quite conceivable that many scripts on the net, not just mine, get
> broken with the unexpected long-named TEMP versions.
>
> The problem with DATET.CMD that Todd brought up, that is totally on me.
> But the TEMP long path dilemma is an anomaly that's not just on my tab.
> Nevertheless, I have corrected it for the eventuality for the
> next release. But inserting the kind of a line above should get you
> going, especially with the high level of script knowledge that you posses.
Sure, we regular posters know how to fix it, but those who look to FAQ
material for solutions are typically those who don't understand such
concepts as what TEMP is for, much less how to get it's short format on
their own. Your point about others forgetting to quote is quite correct,
however the focus is on keeping the FAQ material reliable.
Timo Salmi
> Timo Salmi wrote:
>> It is quite conceivable that many scripts on the net, not just
>> mine, get broken with the unexpected long-named TEMP versions. The
>> problem with DATET.CMD that Todd brought up, that is totally on me.
>> But the TEMP long path dilemma is an anomaly that's not just on my
>> tab.
> Sure, we regular posters know how to fix it, but those who look to
> FAQ material for solutions are typically those who don't understand
> such concepts as what TEMP is for, much less how to get it's short
> format on their own. Your point about others forgetting to quote is
> quite correct, however the focus is on keeping the FAQ material
> reliable.
I fully agree with that assessment. Therefore, I quickly corrected all
such instances I could find at a short notice (pardon the pun) in the
script files included in the FAQ. There in place now. If anyone notices
more of these catches, also the further observations would be highly
welcome.
Timo Salmi
> Or, alternately, perhaps we should start properly considering the
> general case when it comes to filenames.
With the exapction of the temp paths Iäve already tried to take that
route. I'll try to do that also with TEMP and TMP from now on.
> It seems a little sideways to me to use tools that do not do this for
> us, but require us to convert any potentially long filename to short
> format just for the convenience of the tool.
If one writes scrictly in XP script that should not be too much of a
problem. However, if one wants backwards portable (recall that many
batches stem even from the MS-DOS era) the picture is more complicated.
Matthias Tacke
> Todd Vargo <tlv...@sbcglobal.netz> wrote:
>> Sure, we regular posters know how to fix it, but those who look to FAQ
>> material for solutions are typically those who don't understand such
>> concepts as what TEMP is for, much less how to get it's short format
>> on their own. Your point about others forgetting to quote is quite
>> correct, however the focus is on keeping the FAQ material reliable.
>
> I fully agree with that assessment. Therefore, I quickly corrected all
> such instances I could find at a short notice (pardon the pun) in the
> script files included in the FAQ. There in place now. If anyone notices
> more of these catches, also the further observations would be highly
> welcome.
>
Timo, I have a deja vue. Didn't I suggest always quoting already?
http://groups.google.com/group/alt.msdos.batch.nt/msg/2b4e4639f2e0a003
<cite>
for general use and your faq I'd *always* quote to have it working with
file names containing spaces.
</cite>
That was back in Oct 2004.
But better late than never - I appreciate your changes.
It now works without changes (as you know I am able to find myself)
DatetDD=15
DatetMM=02
DatetYY=07
DatetYYYY=2007
DatetWkD=Do
DatetMon=Feb
DatetHH=14
DatetMI=41
DatetSS=51
Greetings
Matthias
Dr J R Stockton
Wed, 14 Feb 2007 16:52:37, Timo Salmi <t...@uwasa.fi> posted:
>Wed 14-Feb-2007: I have made an update
>
> 192436 Feb 14 2007 ftp://garbo.uwasa.fi/pc/link/tscmd.zip
> tscmd43.zip Useful NT/2000/XP script tricks and tips, T.Salmi
>
>Added the scripts
> DATET.CMD Put the current date parts into the environment
> (Aka the mother of all command-line script FAQs)
In the later DATET,
2007-02-14 21:45 3,669 DATET.CMD
VBS part contains
DateNow=Date
TimeNow = Time
If run at midnight, that might conceivably get the date of one day and
the time of the next day. Just use DTNow = Now and replace both
DateNow and TimeNow with DTNow.
As a general rule, any given process should call for the date and/or
time no more than once, unless it has a positive requirement to be
sensitive to the passage of time.
The Day-of-Week Number could be returned by DATET, with due care for
avoiding localisation and 0..6/1..7. At present Day-Of-Week is (I
guess) provided in the chosen local language. If there is doubt about
number localisation, just use (Int(DTNow-2) mod 7)+1 for Mon..Sun =
1..7.
The ISO Week Number could be added, not always correctly, with DatePart
'ww'; - my page vb-date2.htm contains correct code for it.
Since Now returns a daycount from 1899-12-30 00:00:00 local = 0.0, it
would be easy also to return a daycount, either from that or from some
better-chosen origin. CJD, from -4713-11-24 00:00:00 local, would be
best, since it is of constant length for a considerable period of time -
BC 1976/11/08 to AD 22666/12/20 or thereabouts, and can easily be
truncated as needed.
TS> "I can only hope that I got it right now. But testing different
locales from a single one is guesswork at best and waiting for
observations from the others." Agreed. One should set one's system in
accordance with applicable ISO standards, and for test purposes seek
assistance from a colleague who refuses to do likewise.
Regards,
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk DOS 3.3, 6.20 ; WinXP.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <URL:http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <URL:http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.
Timo Salmi
> Timo Salmi <t...@uwasa.fi> posted:
>> DATET.CMD Put the current date parts into the environment
> Just use DTNow = Now and replace both DateNow and TimeNow with DTNow.
Ok. Forthcoming. I am combing for the long-temp issue anyway.
> The Day-of-Week Number could be returned by DATET,
I don't want to "stack" DATET more than currently.
> Regards,
Thanks John.
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
Dr J R Stockton
15 Feb 2007 14:44:55, Matthias Tacke <Matt...@Tacke.de> posted:
>
>DatetDD=15
>DatetMM=02
>DatetYY=07
>DatetYYYY=2007
>DatetWkD=Do
>DatetMon=Feb
>DatetHH=14
>DatetMI=41
>DatetSS=51
Now there's a potential localisation problem and batch-file breaker for
the incautious - the TLA for Thursday in German is apparently "Do" with
only two letters (or is it a typo?). Are two letters used for the other
days of the week? In ASCII, Bengali Catalan and Tibetan would seem to
need four letters, and Breton five.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6.
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.
Matthias Tacke
> Now there's a potential localisation problem and batch-file breaker for
> the incautious - the TLA for Thursday in German is apparently "Do" with
> only two letters (or is it a typo?). Are two letters used for the other
> days of the week? In ASCII, Bengali Catalan and Tibetan would seem to
> need four letters, and Breton five.
>
No typo John, you are right. The t in TLA stands for two in German ;-)
Monday Montag Mo
Tuesday Dienstag Di
Wednesday Mittwoch Mi
Thursday Donnerstag Do
Friday Freitag Fr
Saturday Samstag Sa
Sunday Sonntag So
Timo Salmi
>> DatetDD=15
>> DatetMM=02
>> DatetYY=07
>> DatetYYYY=2007
>> DatetWkD=Do
> Now there's a potential localisation problem and batch-file breaker for
> the incautious - the TLA for Thursday in German is apparently "Do" with
> only two letters (or is it a typo?). Are two letters used for the other
> days of the week? In ASCII, Bengali Catalan and Tibetan would seem to
> need four letters, and Breton five.
True. But the actual relevance ("the mother of all FAQs", i.e. the date
FAQ) primarily is with the first three. Besides "DatetWkD=Do" is correct
localization for Germany as Matthias kindly tells us. And so on,
respectively. E.g. "To" for Finnish, although personally I prefer and
use English on my own PC, so I get "Thu". Furthermore, the weekday
number issue, you brought up earlier, is covered elsewhere in the FAQ.
Timo Salmi
> Thanks Todd, for explaining what I was too tired yesterday night.
> Timo, I have a deja vue. Didn't I suggest always quoting already?
Yes, you did. But put things in perspective. Given the daily download
rate there must have been tens of thousands of them over the years. And
this was the first time anyone came up with the notion of a long-format
TEMP path. Had it been a common problem, it would would have been
brought up more frequently. Other than that, the long-name eventuality
has been reasonably covered in the FAQ even before. Although now that I
am going through it methodologically I have noticed a couple of omissions.
It is a good thing that this reemerged now. Thank you. But there have
been even greater concerns to cover (and also other things for me to do
in my life). So that's "the why" to your implicit question "why not back
then?". Still, I agree with Todd's, John's and your points.
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
Dr J R Stockton
Fri, 16 Feb 2007 07:51:15, Timo Salmi <t...@uwasa.fi> posted:
>Dr J R Stockton <repl...@merlyn.demon.co.uk> wrote:
>> Matthias Tacke <Matt...@Tacke.de> posted:
>>> DatetDD=15
>>> DatetMM=02
>>> DatetYY=07
>>> DatetYYYY=2007
>>> DatetWkD=Do
>
>> Now there's a potential localisation problem and batch-file breaker for
>> the incautious - the TLA for Thursday in German is apparently "Do" with
>> only two letters (or is it a typo?). Are two letters used for the other
>> days of the week? In ASCII, Bengali Catalan and Tibetan would seem to
>> need four letters, and Breton five.
>
>True. But the actual relevance ("the mother of all FAQs", i.e. the date
>FAQ) primarily is with the first three. Besides "DatetWkD=Do" is correct
>localization for Germany as Matthias kindly tells us. And so on,
>respectively. E.g. "To" for Finnish, although personally I prefer and
>use English on my own PC, so I get "Thu".
My real point was that English speakers might presume that exactly three
letters are used in all languages, and compose string-handling code
accordingly.
> Furthermore, the weekday
>number issue, you brought up earlier, is covered elsewhere in the FAQ.
For the next release, would you consider changing the quote in #70
"One should really test Weeks 1, 52 [53] for all 14 possible year types
(leap/non-Leap, starting Mon-Sun)." to "one should at least test ..."?
I've discovered the above test to be inadequate, as VBS function
DatePart, as well as being (as I said before) wrong three times per 28
years, is also discrepant for 2101-01-02 and other dates at 400-year
intervals.
The next error is at the end of this calendar year.
It would be nice to have a report from someone who has tried my VBS page
in Vista.
The FAQ does not provide an answer for those seeking a way of finding
the ISO 8601 week number, which is widely used in Europe. It contains
only one instance of "8601", and, where it does provide week number
code, it does not fully describe or cite the week numbering system in
question.
Re %temp% and quotes : In my XP, there are OTHER
environment variables with Long File Names
Todd Vargo
Dr J R Stockton wrote:
> The FAQ does not provide an answer for those seeking a way of finding
> the ISO 8601 week number, which is widely used in Europe.
But if it did, then what would you have to post about? ;-)
Timo Salmi
>> True. But the actual relevance ("the mother of all FAQs", i.e. the
>> date FAQ) primarily is with the first three. Besides "DatetWkD=Do"
>> is correct localization for Germany as Matthias kindly tells us.
>> And so on,
> My real point was that English speakers might presume that exactly
> three letters are used in all languages, and compose string-handling
> code accordingly.
Errors and bad coding will always be made, no matter what. Some
responsibility must be left with also the user.
> For the next release, would you consider changing the quote in #70
> "One should really test Weeks 1, 52 [53] for all 14 possible year
> types (leap/non-Leap, starting Mon-Sun)." to "one should at least
> test ..."?
Thanks for the tip, John. I'll store it for a potential later
consideration. However, there is a limit to how deep to go. You see, the
true background for my FAQ is what I have happened to need myself. And
then share a part of what has come up. As for the week number, I need it
during the teaching periods. At the rare year end, what I'll factually
do I'll look at my local Finnish calendar. If I ever need to be
absolutely sure if it is 1 or 53.
> The FAQ does not provide an answer for those seeking a way of finding
> the ISO 8601 week number, which is widely used in Europe. It
> contains only one instance of "8601", and, where it does provide week
> number code, it does not fully describe or cite the week numbering
> system in question.
As as indicated, there is a balance between accuracy and how deep to go
with the effort it will take.
> Re %temp% and quotes : In my XP, there are OTHER environment
> variables with Long File Names
Yes. Of course. Have you come upon any such which I have crucially
utilized and omitted to quote?
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