Bonehead batchfile question

[Craig]

O.K. I'm stumped. Why won't this batch file echo what I'm
expecting (the OS version)??? Here it is:

@echo off
echo.
FOR /F "tokens=2* delims= " %%A IN ('REG
QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion" /v ProductName') DO SET os=%%B

If %OS% == Microsoft Windows 2000
goto w2k
If %OS% == Microsoft Windows XP
goto xp

:w2k
echo You're running Windows 2000
pause

:xp
echo You're running Windows XP
pause

 

[Phil Robyn]

O.K. I'm stumped. Why won't this batch file echo what I'm
expecting (the OS version)??? Here it is:

@echo off
echo.
FOR /F "tokens=2* delims= " %%A IN ('REG
QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion" /v ProductName') DO SET os=%%B

If %OS% == Microsoft Windows 2000

If "%OS%" == "Microsoft Windows 2000"

goto w2k
If %OS% == Microsoft Windows XP

If "%OS%" == "Microsoft Windows XP"

 

[Craig]

Thank you, Phil!
I told you it was a bonehead question!

Best Regards,
Craig

 

[Ritchie]

If "%OS%" == "Microsoft Windows 2000"

Craig, also put the GOTO... on the same line as the IF (or use brackets):-

if "%OS%"=="Microsoft Windows 2000" goto w2k

BTW, if I was using REG to determine the OS, I might do something like:-

01. @echo off & setlocal ENABLEEXTENSIONS
02. set k="HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion"
03. set v="ProductName"
04.
05. for /f "delims=" %%a in ('reg query %k% /v %v%') do (
06. for %%b in (%%a) do set ver=%%b
07. )
08.
09. if "%ver%"=="2000" goto w2k
10. if "%ver%"=="XP" goto xp
11.
12. echo/Unknown OS
13. goto :EOF
14.
15. :w2k
16. echo/You're running Windows 2000
17. goto :EOF
18.
19. :xp
20. echo/You're running Windows XP
21. goto :EOF

Line 1 ensures extensions are enabled, see cmd/? and setlocal/?.
Line 2/3 avoids using a long commandline in line 5 (which don't travel
too well).
Line 6 avoids using the tab character (which also doesn't travel too well).
Line 12 catches other OS's.
Instead of using a variable named 'OS', I used 'ver', which avoids redefining
a predefined variable (open a new console window and enter 'set').

 

[guard]

Thank you, Phil!
I told you it was a bonehead question!

Best Regards,
Craig

The Mount/\Command "GetOS" provides the following:

1. Displays the current Operating System
2. Saves the value in #os
3. Sets errorlevel based on the result

GetOS performs CONSISTENTLY under NT/2K/XP/K3. It is included in the FREE
Advanced NT/2K/XP Command Library (http://ntlib.com).

for details and color-keyed examples:
(http://TheSystemGuard.com/MtCmds/GetValue/GetOS.htm)

*******

-tsg
____________________________________________________________
TheSystemGuard.com | BoomingOrFuming.com | MountCommands.com
Free and "Almost Free" Knowledge for Windows System Admins!

 

[Ritchie]

The Mount/\Command "GetOS" provides the following:
1. Displays the current Operating System
GetOS performs CONSISTENTLY under NT/2K/XP/K3. It is included in the FREE

Since you mention it, %.GetOs% CONSISTENTLY fails to determine the correct
OS when the native command interpreter has been replaced. For instance, on
an NT4 machine using cmd.exe from 2000 or XP, %.GetOs% returns '2K' and
'unknown' respectively.

 

[Mark V]

Ritchie wrote in

Since you mention it, %.GetOs% CONSISTENTLY fails to determine the
correct OS when the native command interpreter has been replaced.
For instance, on an NT4 machine using cmd.exe from 2000 or XP,
%.GetOs% returns '2K' and 'unknown' respectively.

So much for "GetOS performs CONSISTENTLY under NT/2K/XP/K3" and
"function identically across all supported platforms" ...

Any more shinola to sell us "Guard"?

 

[guard]

FREE

Since you mention it, %.GetOs% CONSISTENTLY fails to determine the correct
OS when the native command interpreter has been replaced. For instance, on
an NT4 machine using cmd.exe from 2000 or XP, %.GetOs% returns '2K' and
'unknown' respectively.

Clarification:

When "the native command interpreter has been replaced", the OS itself is
NOT CONSISTENT, as far as running shell scripts is concerned.

For example:

The "VER" command returns the following:

[NT Cmd.exe running on NT]

Windows NT Version 4.0

[2K Cmd.exe running on NT]

Microsoft Windows 2000 [Version 4.00.1381]

[XP Cmd.exe running on NT]

Microsoft Windows XP [Version 4.0.1381]

[K3 Cmd.exe returns "Entry Point Not Found" when attempting to run on NT]

*******

The text displayed by VER is from the currently running Command Interpreter
but the version numbers are from the actual OS. Even so, the ".GetOS"
Mount/\Command WILL return the correct OS (NT, in this case) as long as the
COMSPEC variable still points to the original Cmd.exe.

This is because .GetOS executes the "VER" command inside a FOR /F statement,
which passes it to a child Cmd.exe. The system determines WHICH Cmd.exe
will be the parent by expanding the COMSPEC variable, so VER will return (in
this case) "Windows NT Version 4.0".

If, while running Windows NT, the COMSPEC variable is changed to point to
the 2K or the XP version of Cmd.exe, GetOS will return inconsistent results
because the internal VER command displays inconsistently, as shown above.

For a color-keyed explanation, see
(http://TheSystemGuard.com/Booming/THE FIRING ISSUE - 20030108.htm)

*******

Replacing the command interpreter (or other default utilities) is normally
done to correct (perceived) shortcomings and/or deficiencies in the original
files. Most of these deficiencies are easily overcome using what's already
there. Some features, like "delaying the expansion of variables" or
"exiting a script while setting a specific errorlevel", are more cryptic to
code in NT, but not impossible.

To delay variable expansion in NT, see
(http://TheSystemGuard.com/MtCmds/CommandShorthand/ForExpand.htm)

To exit while setting a specific errorlevel in NT, see
(http://TheSystemGuard.com/MtCmds/ExitELn)

*******

When using Command Libraries and Mount/\Commands, there is no need to
replace anything because the "fuming special cases" are taken into account
when the Library is initialized. Write your script ONCE and all commands
work CONSISTENTLY across NT/2K/XP/K3 without making any changes to any of
the OS's, and without mixing and matching files.

The cryptic code is still there, but you do not have to remember it and
retype it constantly. All of the code is in ONE FILE (a Command Library)
that provides hundreds of ONE WORD commands that "sound like what they do".

This is the power of Mount/\Commands.

*******

To Mr. Lawrence:

We do not have a record of your licensing any of our products.
The ".GetOS" command is included in the FREE Advanced NT/2K/XP/K3
Library, available at (http://ntlib.com). Obtaining your own
copy would allow a more accurate analysis of how ".GetOS" performs.

*******

-tsg
____________________________________________________________
TheSystemGuard.com | BoomingOrFuming.com | MountCommands.com
Free and "Almost Free" Knowledge for Windows System Admins!

 

[Ritchie]

When "the native command interpreter has been replaced", the OS itself is
NOT CONSISTENT, as far as running shell scripts is concerned.

Which is why '%.GetOS%' fails as it does not take this in account.

The "VER" command returns the following:

The regulars here, myself included, are well aware of how the VER output
varies with different CI's. It's been thrashed to death many times before.

Mount/\Command WILL return the correct OS (NT, in this case) as long as the
COMSPEC variable still points to the original Cmd.exe.

I've already highlighted the fact that %.GetOS% cannot be replied upon
to return the correct operating system.

If, while running Windows NT, the COMSPEC variable is changed to point to
the 2K or the XP version of Cmd.exe, GetOS will return inconsistent results
Agreed.

files. Most of these deficiencies are easily overcome using what's already
there. Some features, like "delaying the expansion of variables" or
"exiting a script while setting a specific errorlevel", are more cryptic to
code in NT, but not impossible.

Many replace the native CI to increase the maximum commandline length.

We do not have a record of your licensing any of our products.

Likewise. BTW, I don't use my regular email address when there's the
remotest chance it may be spammed.

IMHO, your product would be improved if the %.GetOS% command actually
returned the operating system version, and additional commands were
created to determine the command interpreter in use and the command
interpreter defined by COMSPEC (although both are readily determined
without 'cryptic' code).

Detecting the correct operating system is very important, for example
when applying OS specific patches/updates. For this I prefer parsing
the output of 'net config svr', as I've yet to see it fail under NT4,
2000, XP or 2003.

By detecting the current and COMSPEC defined command interpreter, a
script can exit cleanly if a particalar feature is not available. For
example, I have posted a script that relied heavily on features only
available in a Win 2000 or later command interpreter.

Rather than test for OS, the script determined both the current and
COMSPEC defined CI and if the requirements were not met, a meaningful
message was displayed explaining why the script could not continue,
and what they needed to do to meet the requirements. Consequently,
NT4 users who used a 2000/XP CI had access to the script.

This approach is consistent with Microsft as they also recommend
programmers test for specific features over OS version because the
'missing' feature may become available at a later date in the form
of an update or service pack.

But who knows, may be I'm talking a load of crap and Mt Cmd is currently
at stage one according to Schopenhauer's theory.

 

[Bill Stewart]

I still think it's funny that they're selling batch files.

Detecting the correct operating system is very important, for example
when applying OS specific patches/updates. For this I prefer parsing the
output of 'net config svr', as I've yet to see it fail under NT4, 2000,
XP or 2003.

I completely agree. But in all of these cases, as you've pointed out,
variability in the client systems can cause all kinds of different
failures. Replacing cmd.exe to get past the 2K line length limit is one. A
broken PATH (how many times does the "how come I get 'bad command or file
name' after typing commands?" question get asked in this group) is another.
I have seen these kinds of problems (and others) particularly in large,
heterogeneous environments where client machines are not controlled by
centralized policy and users have administrative control over their own
machines because they're research scientists or programmers. To use the
"net config server" example, it would have problems on machines where
file/printer sharing isn't installed, wouldn't it? My point is primarily
that Mr. Spammer's batch files would likely have a fairly significant
failure rate in these kinds of environments, and potential users need to be
aware of these kinds of possibilities.

That's the whole reason I wrote the osver.exe freeware tool. Quick, easy,
even runs on Windows 9x. Plus, it's much faster than parsing textual output
from another command.

Just my $0.02 worth.

Thanks,

Bill

 

[Al Dunbar]

Ritchie wrote in

So much for "GetOS performs CONSISTENTLY under NT/2K/XP/K3" and
"function identically across all supported platforms" ...

Any more shinola to sell us "Guard"?

Heh. On the other hand, if it doesn't perform CONSISTENTLY, then that must
not be a supported platform.

/Al

 

[Ritchie]

Hey Evelyn, or whatever your name is, you sent me ntlib.cmd via
email about a year ago.

After I loaded it, I typed:-

set ""

I still think it's funny that they're selling batch files.

If you think that's funny, how about the idea of someone actually buying
them?

broken PATH (how many times does the "how come I get 'bad command or file
name' after typing commands?" question get asked in this group) is another.

I see what you're getting at, but it's not really relevant here. If a
machine is broken you can't assume it's more likely to succeed running
a script that relies on TPU's that a script that relies on built-in
utils.

machines because they're research scientists or programmers. To use the
"net config server" example, it would have problems on machines where
file/printer sharing isn't installed, wouldn't it? My point is primarily

that Mr. Spammer's batch files would likely have a fairly significant
failure rate in these kinds of environments, and potential users need to be
aware of these kinds of possibilities.

That's right, where on earth do you start to debug such an obfuscated
batch file that is uncommented and uses undocumented features.

That's the whole reason I wrote the osver.exe freeware tool. Quick, easy,
even runs on Windows 9x. Plus, it's much faster than parsing textual output
from another command.

I've nothing against TPU, I use them every day and even write my own from
time to time. Unfortunately it's just not always possible to install or make
these utils available to all machines, especially if the network belongs to
someone else, and understandably so.

In these situations it's handy to have at hand scripts that only rely on
built-in utils, blah blah...

IMHO, just one of the major shortcomings of the spammers product is that
a script now relies on a 'loaded library' which is akin to relying a on
TPU. And by definition of the spammers own admission, his product doesn't
do anything that can't already be done using the built-in tools.

 

[Al Dunbar [MS-MVP]]

Hey Evelyn, or whatever your name is, you sent me ntlib.cmd via
email about a year ago.

After I loaded it, I typed:-

set ""

Are now going to accuse me of reverse engineering? <g>
LOL!


If you think that's funny, how about the idea of someone actually buying
them?

Actually, I think it rather a shame. But hey, I have some .txt files I will
gladly sell to anyone with a couple of bucks to spare.

another.

I see what you're getting at, but it's not really relevant here. If a
machine is broken you can't assume it's more likely to succeed running
a script that relies on TPU's that a script that relies on built-in
utils.

In fact, one can assume anything, but then one reserves the right to be
wrong.

That's right, where on earth do you start to debug such an obfuscated
batch file that is uncommented and uses undocumented features.

In fact, I think they rely somewhat heavily on Alchemy for some of the core
functions...

I've nothing against TPU, I use them every day and even write my own from
time to time. Unfortunately it's just not always possible to install or make
these utils available to all machines, especially if the network belongs to
someone else, and understandably so.

In these situations it's handy to have at hand scripts that only rely on
built-in utils, blah blah...

Certainly sounds safer than having at hand scripts that rely on *OTHER*
scripts that themselves only rely on built-in utils, especially when you
cannot feasibly read them to verify this fact, but must take the word of a
spammer.

IMHO, just one of the major shortcomings of the spammers product is that
a script now relies on a 'loaded library' which is akin to relying a on
TPU. And by definition of the spammers own admission, his product doesn't
do anything that can't already be done using the built-in tools.

Exactly. Of course, I believe he would claim that he has done the difficult
parts *for* his customers.

Mind you, when it comes time for that customer to write what would, for most
people, be a simple five-line batch script, seems to me he is likely to wind
up with a five line script that loads ntlib and then calls some of it. Might
be OK for some, but those would be the people who run spellchecker on
EVERYTHING they type, and possibly everything they receive.

/Al

 

[Bill Stewart]

If you think that's funny, how about the idea of someone actually buying
them?

Quite sad, actually, since the potential customer may have a mess that he
is not qualified to fix, and will have to pay someone else to clean it up.

I see what you're getting at, but it's not really relevant here. If a
machine is broken you can't assume it's more likely to succeed running a
script that relies on TPU's that a script that relies on built-in utils.

Well, that's true no matter what kind of program you run. I guess I was
trying to say that, in my experience, batch files are more likely to behave
unpredictably and fail in heterogeneous environments than other kinds of
programs.

Did I say 'net config svr'? Make that 'net config work' <g> That seems
to work very well indeed, even without F&P.

OK -- but does that also work on Win9x?

I've nothing against TPU, I use them every day and even write my own from
time to time. Unfortunately it's just not always possible to install or
make these utils available to all machines, especially if the network
belongs to someone else, and understandably so.

I understand this and agree with the premise. It's not always feasible.
That's one of the reasons WSH scripts are quite useful also.

Bill

 

[Ritchie]

Well, that's true no matter what kind of program you run. I guess I was
trying to say that, in my experience, batch files are more likely to behave
unpredictably and fail in heterogeneous environments than other kinds of
programs.

That's because bad batch files are so easy to write, bad EXE's aren't quite
so easy.

OK -- but does that also work on Win9x?

I very much doubt it. But then I honestly haven't seen a w9x/me box in a
work environment for at least three years. But may be I'm a bit fussy

That's one of the reasons WSH scripts are quite useful also.

Yer, I really ought to make more of an effort to learn WSH/VBS.

 

[Ritchie]

In fact, one can assume anything, but then one reserves the right to be
wrong.

I thought you'd say that <g>

 

[Roger Grossenbacher]

Ritchie wrote in

So much for "GetOS performs CONSISTENTLY under NT/2K/XP/K3" and
"function identically across all supported platforms" ...

Any more shinola to sell us "Guard"?

Heh. On the other hand, if it doesn't perform CONSISTENTLY, then that must
not be a supported platform.

/Al