5.23 LTS, 5.31 beta 1 - ExamineEnvironmentVariables()

[Little John]

I encountered the following bug with both PB 5.23 LTS x64 and PB 5.31 beta 1 x 64 on Windows 7.

Code: Select all

If ExamineEnvironmentVariables()
   While NextEnvironmentVariable()
      Debug EnvironmentVariableName() + "=" + EnvironmentVariableValue()
   Wend  
EndIf

=::=::\
ALLUSERSPROFILE=C:\ProgramData
[...]

ALLUSERSPROFILE=C:\ProgramData
[...]

I.e. PB accidentally adds an environment variable with name="" and value="::=::\" to the list.

[freak]

Its not an accident. This environment variable (and others) actually exists: http://stackoverflow.com/questions/1043 ... -variables

[Little John]

Uuuh!
But why does the built-in Windows command "set" not show this environment variable?

And according to the output of the code in my previous post, the name of this envirionment variable is an empty string.
If this is a valid name, then the following code should give me the value of that variable, no?

Code: Select all

Debug GetEnvironmentVariable("")   ; should yield ::=::\

But when I try to run this code, PB complains, saying

The Environment Variable name is empty.

Shouldn't the behaviours of EnvironmentVariableName() and GetEnvironmentVariable() be consistent,
either both tolerating an empty variable name, or both not tolerating an empty variable name?

[freak]

What can I say, its a Windows oddity

[luis]

AFAIK these should be visible only if you started the program from the command prompt.

Did you see them anyway ? I don't see them running your program from the IDE.

If I change it this way:

Code: Select all

OpenConsole()
 If ExamineEnvironmentVariables()
   While NextEnvironmentVariable()
      PrintN(EnvironmentVariableName() + "=" + EnvironmentVariableValue())
   Wend 
EndIf 
CloseConsole()

and I run it from the prompt then I see them.

BTW: they have a name, why do you think they don't have one ? Oh, maybe you saw only that one ?

They should be called "=C:" for C:, "=F:" for F: etc., so in your case you should try GetEnvironmentVariable() using "=::" as the name.

I'm not sure about that one... maybe it's some kind of placeholder ?

EDIT: ah, no, according to one of the answer (from Chen) -> "It's a bug in Windows that it created the bogus environment variable in the first place."

BTW, I don't see the "bogus" one. Win7 x64.

And yes, SET does not show them, probably because they are intended to be for private use of the command prompt.

[Little John]

AFAIK these should be visible only if you started the program from the command prompt.

Did you see them anyway ? I don't see them running your program from the IDE.

Yes, I saw them in the IDE, using PB 5.23 x64 and PB 5.31 beta 1 x64 on Windows 7.

If I change it this way:

Code: Select all

OpenConsole()
 If ExamineEnvironmentVariables()
   While NextEnvironmentVariable()
      PrintN(EnvironmentVariableName() + "=" + EnvironmentVariableValue())
   Wend 
EndIf 
CloseConsole()

and I run it from the prompt then I see them.

With this code, I get two strange lines:

=::=::\
=C:=C:\Users\LJ\Desktop

That means, when using Debug output in the IDE, and using console output, we get different results.

BTW: they have a name, why do you think they don't have one ? Oh, maybe you saw only that one ?

Sorry, I probably didn't express myself clear enough.
Yes, I only saw that one odd line.

And when I change the code a little:

Code: Select all

If ExamineEnvironmentVariables()
   While NextEnvironmentVariable()
      Debug "#" + EnvironmentVariableName() + "# = #" + EnvironmentVariableValue() + "#"
   Wend  
EndIf

then I get the following result:

## = #::=::\#

This shows better what I mean: EnvironmentVariableName() returns an empty string
(and I didn't know that an empty string can be a valid name of an environment variable).

[helpy]

See http://ss64.com/nt/syntax-variables.html :

Undocumented Dynamic variables (read only)

%__CD__% The current directory, terminated with a trailing backslash.
%=C:% The current directory of the C: drive.
%=D:% The current directory of the D: drive if drive D: has been accessed in the current CMD session.
%DPATH% Related to the (deprecated) DPATH command.
%=ExitCode% The hex value of the last return code set by EXIT /B
%=ExitCodeAscii% The ASCII value of the last return code set by EXIT /B if greater than 32.
%KEYS% Related to the (deprecated) KEYS command.

[luis]

With this code, I get two strange lines:
=::=::\
=C:=C:\Users\LJ\Desktop
That means, when using Debug output in the IDE, and using console output, we get different results.

Yes, I think it's as I was saying above: you get the "private" CMD.exe variables ONLY running the process from the console (indeed you get this new one -> "=C:" = "C:\Users\LJ\Desktop").

The other var you get ("=::" = "::\") it's a consequence of a bug, and evidently you get it always, even when the CMD.EXE it's not the parent of your process. I don't have the "bugged" one for some reason.

This shows better what I mean: EnvironmentVariableName() returns an empty string

And that is strange, since the EnvironmentVariableValue() seems to return both the name of the var + its value combined. I don't think that's correct, but also that var according to Chen is the result of a bug, so maybe this anomaly it's also a consequence of that (EnvironmentVariableName() is returning an "impossible" value = "").

Hmm.... on second thought... let me do a test.

[luis]

OK, at least now is a little more clear.

PB's EnvironmentVariableName() and EnvironmentVariableValue() simply does not work with these "private" variables.

For example, I have a var "=C:" with value "C:\Users\luis\Desktop\TEST"

EnvironmentVariableName() returns "" instead of "=C:".

EnvironmentVariableValue() returns "C:=C:\Users\luis\Desktop\TEST" instead of "C:\Users\luis\Desktop\TEST".

All this because according to the documentation of GetEnvironmentStrings() -> http://msdn.microsoft.com/en-us/library ... 85%29.aspx

The GetEnvironmentStrings function returns a pointer to a block of memory that contains the environment variables of the calling process (both the system and the user environment variables). Each environment block contains the environment variables in the following format:

Var1=Value1\0
Var2=Value2\0
Var3=Value3\0
...
VarN=ValueN\0\0

So I suppose PB parse the buffer according to the documentation, and consequently it fails for the undocumented private variables (the starting '=' creates havoc). Maybe that's why this format was chosen at the time, it's an invalid environment variable name (starting with '=').

On the other hand, GetEnvironmentVariable("=C:") returns correctly "C:\Users\luis\Desktop\TEST" (probably because does not have to parse anything and uses another API call altogether).

[Little John]

Thank you for the additional investigation and explanation!