Page 1 of 1

5.23 LTS, 5.31 beta 1 - ExamineEnvironmentVariables()

Posted: Sat Sep 06, 2014 4:50 pm
by 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
Debug wrote:=::=::\
ALLUSERSPROFILE=C:\ProgramData
[...]
Windows command ''set'' wrote:ALLUSERSPROFILE=C:\ProgramData
[...]
I.e. PB accidentally adds an environment variable with name="" and value="::=::\" to the list.

Re: 5.23 LTS, 5.31 beta 1 - ExamineEnvironmentVariables()

Posted: Sat Sep 06, 2014 7:14 pm
by freak
Its not an accident. This environment variable (and others) actually exists: http://stackoverflow.com/questions/1043 ... -variables

Re: 5.23 LTS, 5.31 beta 1 - ExamineEnvironmentVariables()

Posted: Sat Sep 06, 2014 7:58 pm
by 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?

Re: 5.23 LTS, 5.31 beta 1 - ExamineEnvironmentVariables()

Posted: Sat Sep 06, 2014 8:10 pm
by freak
What can I say, its a Windows oddity :)

Re: 5.23 LTS, 5.31 beta 1 - ExamineEnvironmentVariables()

Posted: Sat Sep 06, 2014 8:12 pm
by 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.

Re: 5.23 LTS, 5.31 beta 1 - ExamineEnvironmentVariables()

Posted: Sat Sep 06, 2014 9:05 pm
by Little John
luis wrote: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.
luis wrote: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:
Console wrote:=::=::\
=C:=C:\Users\LJ\Desktop
That means, when using Debug output in the IDE, and using console output, we get different results. :?
luis wrote: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:
Debug wrote:## = #::=::\#
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).

Re: 5.23 LTS, 5.31 beta 1 - ExamineEnvironmentVariables()

Posted: Sat Sep 06, 2014 9:20 pm
by 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.

Re: 5.23 LTS, 5.31 beta 1 - ExamineEnvironmentVariables()

Posted: Sat Sep 06, 2014 9:21 pm
by luis
Little John wrote: 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.
Little John wrote: 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.

Re: 5.23 LTS, 5.31 beta 1 - ExamineEnvironmentVariables()

Posted: Sat Sep 06, 2014 9:58 pm
by 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
MSDN wrote: 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).

Re: 5.23 LTS, 5.31 beta 1 - ExamineEnvironmentVariables()

Posted: Sun Sep 07, 2014 11:00 am
by Little John
Thank you for the additional investigation and explanation!