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

Craig wrote:

> 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"

> goto xp
>
> :w2k
> echo You're running Windows 2000
> pause
>
> :xp
> echo You're running Windows XP
> pause


--
Phil Robyn
Univ. of California, Berkeley

u n z i p m y a d d r e s s t o s e n d e - m a i l

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

Best Regards,
Craig

>-----Original Message-----
>Craig wrote:
>
>> 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"
>
>> goto xp
>>
>> :w2k
>> echo You're running Windows 2000
>> pause
>>
>> :xp
>> echo You're running Windows XP
>> pause
>
>
>--
>Phil Robyn
>Univ. of California, Berkeley
>
>u n z i p m y a d d r e s s t o s e n d e - m a
i l
>
>.
>

"Phil Robyn" <(E-Mail Removed)> wrote in message news:#(E-Mail Removed)...
> > If %OS% == Microsoft Windows 2000
>
> If "%OS%" == "Microsoft Windows 2000"
>
> > goto w2k

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').

--
Ritchie, undo for mail

"Craig" <(E-Mail Removed)> wrote in message
news:110301c38609$5bada480$(E-Mail Removed)...
> Thank you, Phil!
> I told you it was a bonehead question! :-)
>
> Best Regards,
> Craig
>
> >-----Original Message-----
> >Craig wrote:
> >
> >> 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"
> >
> >> goto xp
> >>
> >> :w2k
> >> echo You're running Windows 2000
> >> pause
> >>
> >> :xp
> >> echo You're running Windows XP
> >> pause
> >
> >
> >--
> >Phil Robyn
> >Univ. of California, Berkeley
> >
> >u n z i p m y a d d r e s s t o s e n d e - m a
> i l
> >

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!

"guard" <^T^S^G^n^e^w^s^@TheSystemGuard.com> wrote in message news:ble44v$bf4am$(E-Mail Removed)...
> 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.

--
Ritchie, undo for mail

Ritchie wrote in news:3f7a9e39$0$6633$(E-Mail Removed):

> "guard" <^T^S^G^n^e^w^s^@TheSystemGuard.com> wrote in message
> news:ble44v$bf4am$(E-Mail Removed)...
>> 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.

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"?

"Ritchie" wrote
> "guard" wrote
> > 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.

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/TH...2020030108.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/Com.../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!

"guard" <^T^S^G^n^e^w^s^@TheSystemGuard.com> wrote in message news:blept5$bjm4u$(E-Mail Removed)...
> 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.

--
Ritchie, undo for mail

Ritchie <(E-Mail Removed)> wrote:

> the guard spammer wrote:
>
> > We do not have a record of your licensing any of our products.

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