GetEnvVar>Path not working on 64 bit Win 7

Technical support and scripting issues

Moderators: JRL, Dorian (MJT support)

User avatar
Marcus Tettmar
Site Admin
Posts: 7395
Joined: Thu Sep 19, 2002 3:00 pm
Location: Dorset, UK
Contact:

Post by Marcus Tettmar » Fri Jan 14, 2011 10:03 am

I think we've now determined what the problem is with GetEnvVar and will get it fixed in the next maintenance release.
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar

Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?

User avatar
jpuziano
Automation Wizard
Posts: 1085
Joined: Sat Oct 30, 2004 12:00 am

Post by jpuziano » Fri Jan 14, 2011 8:23 pm

mtettmar wrote:I think we've now determined what the problem is with GetEnvVar and will get it fixed in the next maintenance release.
That's what I like to hear, thanks Marcus.
jpuziano

Note: If anyone else on the planet would find the following useful...
[Open] PlayWav command that plays from embedded script data
...then please add your thoughts/support at the above post - :-)

BobDDstryr
Junior Coder
Posts: 38
Joined: Fri Oct 22, 2010 2:47 am

Post by BobDDstryr » Sat Jan 29, 2011 3:30 am

This may not be related; I'm running a machine with Vista64, and several variables don't seem to be working with GetEnvVar.

In a command window, I've typed set, and among the values there:
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)PROCESSOR_ARCHITECTURE=AMD64
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=170a

however when I use the getenvvar for these values and print them out, I get:
Program Files: Program Files (x86)
Program Files (x86): Program Files (x86)
PROCESSOR_ARCHITECTURE: x86
PROCESSOR_LEVEL: (blank)
PROCESSOR_REVISION: (blank)

Any idea why the GetEnvVar command isn't returning the same values as when I just type "set" and look at them? Is this the same issue as reported here? And if so, do you know when the next maintenance release will be? If not, do you either know how to fix this issue, or need any additional information from me?

This is with version 12.1.2

User avatar
jpuziano
Automation Wizard
Posts: 1085
Joined: Sat Oct 30, 2004 12:00 am

Post by jpuziano » Sat Jan 29, 2011 6:34 am

Hi BobDDstryr,
BobDDstryr wrote:Any idea why the GetEnvVar command isn't returning the same values as when I just type "set" and look at them? Is this the same issue as reported here? And if so, do you know when the next maintenance release will be? If not, do you either know how to fix this issue, or need any additional information from me?

This is with version 12.1.2
A fix was just delivered in maintenance release 12.1.4 that should make things better, for path anyway. Please upgrade to 12.1.4 and then tell us what results you are getting.

Marcus, I tested every environment variable existing on my work machine (XP SP3)... comparing results from typing "SET" in a DOS box... to using your GetEnvVar> command.

Path is working fine in 12.1.4 - thanks... however when I run this...

Code: Select all

GetEnvVar>PROMPT,VarResult
MDL>%VarResult%
It comes back with nothing...

However if I open a DOS box and type SET at the command prompt, I can see that:
DOS SET command wrote:PROMPT=$P$G
Can you please work your magic for the "PROMPT" environment variable as well?
jpuziano

Note: If anyone else on the planet would find the following useful...
[Open] PlayWav command that plays from embedded script data
...then please add your thoughts/support at the above post - :-)

User avatar
Marcus Tettmar
Site Admin
Posts: 7395
Joined: Thu Sep 19, 2002 3:00 pm
Location: Dorset, UK
Contact:

Post by Marcus Tettmar » Sat Jan 29, 2011 7:09 am

Can you please work your magic for the "PROMPT" environment variable as well?
No. My magic is limited to the way Windows works. And I can't get the value of something that doesn't exist. You would do well to read up on what environment variables are and how environment variables belong to process blocks and are only available to the same process or a process called by that process.

PROMPT belongs to the command console. Not Windows. If you create the following script:

GetEnvVar>PROMPT,strPromptVar
MessageModal>strPromptVar

You will find that if you run this from within Macro Scheduler you will see an empty string.

Now compile the macro.

If you run the compiled macro from within Windows (e.g. a desktop shortcut or Windows Explorer) you will see an empty string.

Now open up a CMD.EXE console and run the same exe from there and it will display the value that PROMPT is set as you see it when you type SET.

I'm sure I've linked to this in the past but here it is anyway:
http://msdn.microsoft.com/en-us/library ... s.85).aspx

Note what this says about how each process has an environment block and it inherits its environment block from it's parent process. PROMPT is set by the CMD.EXE process NOT by Windows.
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar

Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?

User avatar
jpuziano
Automation Wizard
Posts: 1085
Joined: Sat Oct 30, 2004 12:00 am

Post by jpuziano » Sat Jan 29, 2011 7:22 am

Yes... makes perfect sense... thanks for taking the time to explain about PROMPT so well... something that I could/should have read about in Microsoft documentation... sorry about that.

Take care
jpuziano

Note: If anyone else on the planet would find the following useful...
[Open] PlayWav command that plays from embedded script data
...then please add your thoughts/support at the above post - :-)

BobDDstryr
Junior Coder
Posts: 38
Joined: Fri Oct 22, 2010 2:47 am

Post by BobDDstryr » Tue Feb 01, 2011 1:08 am

Hey guys,

So I upgraded to 12.1.4, but I'm still not getting the right values.

I did figure out what was wrong with the commands that were returning blank values - I'd mistakenly added an extra character.

However, ProgramFiles and PROCESSOR_ARCHITECTURE are still returning the values for a 32-bit machine, while the OS is 64-bit - and typing "set" in a command window verifies that.

from "set" typed at the command line:
ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)
PROCESSOR_ARCHITECTURE=AMD64

however, the scripts from macro scheduler:
GetEnvVar>ProgramFiles,Programs
GetEnvVar>ProgramFiles(x86),Programs2
GetEnvVar>PROCESSOR_ARCHITECTURE,processor

messagemodal>%Programs%
messagemodal>%Programs2%
messagemodal>%processor%
returns:
C:\Program Files (x86)
C:\Program Files (x86)
x86

Any idea why these values don't seem to match up? Alternately, I'm trying to write a script that runs a program that has two versions - one 32-bit and one 64-bit - and so chooses which to run as appropriate - do you know of a different way to differentiate which OS is currently installed (vista32 vs vista64, win7-32 vs win7-64)?

Thanks.

BobDDstryr
Junior Coder
Posts: 38
Joined: Fri Oct 22, 2010 2:47 am

Post by BobDDstryr » Tue Feb 01, 2011 1:25 am

One more bit of information, which may say that there's nothing you can do. I added the line:
run>cmd.exe /C set>>blaarg.txt

blaarg.txt shows that running set this way:
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_ARCHITEW6432=AMD64
ProgramFiles=Program Files (x86)
ProgramFiles(x86)=Program Files (x86)

So I guess back to my question at the end of the last comment - is there an easy way to tell if an installation is 32-bit or 64-bit?

-j

User avatar
Marcus Tettmar
Site Admin
Posts: 7395
Joined: Thu Sep 19, 2002 3:00 pm
Location: Dorset, UK
Contact:

Post by Marcus Tettmar » Tue Feb 01, 2011 9:02 am

Macro Scheduler is 32 bit so it is running under the 32 bit subsystem. Hence the environment variables will be the 32 bit ones and show Program Files (x86).

To get the 64 bit program folder 32 bit apps can query the ProgramW6432 environment variable:

GetEnvVar>ProgramW6432,p64

If it's empty then I guess you won't be on a 64 bit OS.
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar

Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?

BobDDstryr
Junior Coder
Posts: 38
Joined: Fri Oct 22, 2010 2:47 am

Post by BobDDstryr » Tue Feb 01, 2011 7:06 pm

I'd figured it was something like that - thanks Marcus.

Post Reply
Sign up to our newsletter for free automation tips, tricks & discounts