Environment related bugs?

[vmguy]

I created this testcase because a  larger piece of code was failing in a way I couldn't explain.
I submit that the first "Works:" example below should work for all examples.

The AutoIt feature I'm testing is the retrieval of environment variables
and the special Option treatment of variables in strings.

; Help > Function Reference > Environment Management > EnvGet
; Help > Function Reference > Misc. Management > AutoItSetOption
#include <AutoItConstants.au3>

Opt("ExpandEnvStrings", 1) ;0=don't expand, 1=do expand
Opt("ExpandVarStrings", 1) ;0=don't expand, 1=do expand

Local $windir = EnvGet('WinDir')   ;; "windir" EnvGet is case insensitive

ConsoleWrite("Works: temp = %temp% or %TMP% @CRLF@")
ConsoleWrite("Works: $windir = " & $windir & @CRLF)

ConsoleWrite("Fails: @WindowsDir = @WindowsDir@ @CRLF@" & @CRLF) ;; @WindowsDir
ConsoleWrite("Fails: $windir = $windir$ @CRLF@" & @CRLF)         ;; $windir
ConsoleWrite("Fails: %windir = %windir% @CRLF@" & @CRLF)         ;; %windir

;----------------- Retrieve the environment
Local $iPID = Run(@ComSpec, @SystemDir, @SW_MINIMIZE, $STDIN_CHILD + $STDOUT_CHILD)
StdinWrite($iPID, "set @CRLF@ exit @CRLF@")
ProcessWaitClose($iPID)
While 1
        $sOutput = StdoutRead($iPID)
        If @error Then ExitLoop
        ConsoleWrite($sOutput & @CRLF)
     WEnd

#cs And if you prefer Array Display
#include <Array.au3>
Local $sOutput = StdoutRead($iPID)
Local $aArray = StringSplit(StringTrimRight(StringStripCR($sOutput), StringLen(@CRLF)), @CRLF)
_ArrayDisplay($aArray)
#ce Array Display

I confirmed the environment variables in question exist.
The code used to extract the environment isn't quite fair;

• The script runs in the autoit3.exe environment (a 32-bit process)
• The retrieval of environment variables is done with @ComSpec (  cmd is a 64-bit process )
• Some Env variables are different, but variables related to this  test are the same.
• AutoIt Macros, of course,  are independent of Windows environment variables ( @CRLF, @WindowsDir )

The test output:

Works: temp = C:\Users\Richard\AppData\Local\Temp or C:\Users\Richard\AppData\Local\Temp 
Works: $windir = C:\WINDOWS

Fails: @WindowsDir = @WindowsDir@ @CRLF@
Fails: $windir = $windir$ @CRLF@
Fails: %windir = %windir%

• I've Opt'd to have strings expand Var and Env variables:  e.g., $var$, @macro@, %windir%
  In first test everything expands fine:  %temp%, %TMP%, and @CRLF@
  In the second test I explicit catenate the $windir variable to the string.
• In the Failing test, "$windir " should be treated as plain text, and it is.
  $windir$, @CRLF@ should be expanded because of Opt("ExpandVarStrings", 1)
• Failing test "%windir% did not expand;  but %TMP% in the first example did.

Can anyone spot a  problem with the test case?

Aside:  Environment variables are inherited from the parent process.
Between 32-bit autoit.exe and 64-bit cmd.exe, the following variables are different.

autoit.exe  (32-bit)
PROCESSOR_ARCHITECTURE = x86
PROCESSOR_ARCHITEW6432 = AMD64
ProgramFiles       = C:\Program Files (x86)
CommonProgramFiles = C:\Program Files (x86)\Common Files

cmd.exe (64-bit)
PROCESSOR_ARCHITECTURE = AMD64
ProgramFiles       = C:\Program Files
CommonProgramFiles = C:\Program Files\Common Files
Prompt = $P$G

Common to both environments (lower-case):
windir = C:\Windows

 

Edited May 27, 2017 by vmguy

[mikell]

Helpfile says
ExpandVarStrings . 1 = expand variables (when in this mode and you want to use a literal $ or @ then double it up

So you might try this

#include <AutoItConstants.au3>

Opt("ExpandEnvStrings", 1) ;0=don't expand, 1=do expand
Opt("ExpandVarStrings", 1) ;0=don't expand, 1=do expand

Local $windir = EnvGet('WinDir')   ;; "windir" EnvGet is case insensitive

ConsoleWrite("Works: temp = %temp% or %TMP% @CRLF@")
ConsoleWrite("Works: $$windir = " & $windir & @CRLF)

ConsoleWrite("Fails: @@WindowsDir = @WindowsDir@ @CRLF@" & @CRLF) ;; @WindowsDir
ConsoleWrite("Fails: $$windir = $windir$ @CRLF@" & @CRLF)         ;; $windir
ConsoleWrite("Fails: %%windir = %windir% @CRLF@" & @CRLF)         ;; %windir

 

[vmguy]

I've created a second test case from an AutoIt Example.

Opt("ExpandVarStrings", 1)  is unreliable and I haven't yet determined what triggers the failures.

This example taken from:
 

;  Help > AutoIt > Keyword Reference > Func...Return...EndFunc
;        \AutoIt3\Examples\Helpfile\Func.au3
;  Help > AutoIt > Function Reference > Misc. Management > ExpandVarStrings
;        \AutoIt3\Examples\Helpfile\AutoItSetOption.au3

The test case is attached.

Programmer's Credo [1960]
   We do these things,
   Not because they are easy,
   But because we thought they were going to be easy.

Bug_Func.au3

Edited June 1, 2017 by vmguy

[mikell]

3 hours ago, vmguy said:

Opt("ExpandVarStrings", 1)  is unreliable

No. Users who make syntax errors because they don't read helpfile recommendations are.

 

3 hours ago, vmguy said:

I haven't yet determined what triggers the failures.

Did you even read (and test) my previous post ?

MsgBox($MB_SYSTEMMODAL, "", " 1a. Works: Today is " & Today() & "@CRLF@ 1b. Fails: $$iFoo equals $iFoo$ ")  
    Swap($iFoo, $iBar)
    MsgBox($MB_SYSTEMMODAL, "", "After swapping $$iFoo and $$iBar: @CRLF@ 2. Fails: $$iFoo now contains $iFoo$ " ) 
    MsgBox($MB_SYSTEMMODAL, "", "Finally: @CRLF@ 3. Works: The larger of 3 and 4 is " & _Max(3, 4))

 

[vmguy]

10 hours ago, mikell said:

> No. Users who make syntax errors because they don't read helpfile recommendations are.

I only just saw your post.  I had a  browser link to a wrong area of the forum that
didn't allow me to see the post alerts.  I regret not seeing it sooner;  it helped alot.
I did make an extra  effort to document the Help files I was reading in my post.

; Help > Function Reference > Environment Management > EnvGet
; Help > Function Reference > Misc. Management > AutoItSetOption

Here is the ExpandVarStrings Help  text:

Opt("ExpandVarStrings", 1) 

Changes how literal strings and variable/macro ($ and @) symbols are interpreted. 
By default strings are treated literally, this option allows you to use variables 
and macros inside strings, e.g., "The value of var1 is $var1$".
0 = (default) do not expand variables
1 = expand variables 
when in this mode and you want to use a literal $ or @ then double it up: 
"This is a single dollar $$ sign".

Your example did finally let me see why my code was failing,
The point about doubling up ( $$ @@ %% ), didn't cover the situation I  was seeing.

Without doubling, "$windir" is in the result string as literal text, as I intended.

ConsoleWrite("Works: $windir = " & $windir & @CRLF)
Works: $windir = C:\WINDOWS

The problem happens when a string containing a single $,@,% at the beginning,
apparently confuses the parser to catch the rest of the decorated strings
and exposes an unstated rule.

In the following example,

- The first line is the proper way to write this.
  Paraphrased: you must have paired decorators;  they need not be adjacent.
  $$windir just has them together;  they match and don't confuse the parser.

- The second line shows a  partial failure ... perhaps because there are two
  parsers, 2 sets of rules .  ( ExpandVar, ExpandEnv )

  $windir does not interfere with the expansion of %windir%,
  but it fails to expand macro @CRLF@.

ConsoleWrite("Works: $$windir = %windir% @CRLF@")
ConsoleWrite("Fails:  $windir = %windir% @CRLF@")

Works:  $windir = C:\WINDOWS 
Fails:  $windir = C:\WINDOWS @CRLF@

The example in the Help file works, but it fails to explain the parsing restrictions in force.

In my example above you can see that "$windir" is expanded literally, without being doubled.
The problem:  it  has side-effects that are not revealed by "careful reading of the Help".

ConsoleWrite("This is a single dollar $$ sign" & @CRLF)
ConsoleWrite("This is a single dollar $ sign"  & @CRLF)

This is a single dollar $ sign
This is a single dollar $ sign

@Mikell Thanks for your  example.  It helped to clear  my confusion.

 

Edited June 2, 2017 by vmguy

[mikell]

11 hours ago, vmguy said:

it  has side-effects that are not revealed by "careful reading of the Help"

Yes    I agree with that because of the example below

Opt("ExpandVarStrings", 1)
Opt("ExpandEnvStrings", 1)
ConsoleWrite("Fails: $windir = %windir% @CRLF@")
ConsoleWrite("@CRLF@")  ; works
ConsoleWrite(@CRLF)        ; works
ConsoleWrite("Works: $windir = " & "%windir% @CRLF@")  ; <<< ??
ConsoleWrite("Works: $$windir = %windir% @CRLF@")

But personally, instead of trying to understand how AutoIt internally handles all this stuff and how I may hazardously manage exceptions, I prefer to strictly follow helpfile recommendations (doubling markers up) so I never get issues 

 

 

[vmguy]

On 6/2/2017 at 5:05 AM, mikell said:

 I prefer to strictly follow helpfile recommendations

We obviously have different backgrounds.

Doubling $ was not a "recommendation"  in the helpfile;  it was a flat out assertion that you must do something,
which was demonstrably false.  There was no example that demonstrated the requirement to double.
The example showed an unadorned "$" character ... the example was too simple to understand the
fundamentals of the parser for more complicated cases like the name of an AutoIt variable.

I prefer to NEVER trust the documentation.  There are several places in AutoIt where the documentation
has not kept up with changes in the implementation, so I rigorously test everything before proceeding
to write code that I may have to change in many places when I discover the implementation doesn't match the documentation.

If AutoIt was still open source, it would be far simpler to discover why something is failing and then
provide feedback/patches/doc changes to development.

With closed source I have to reverse engineer failures, which takes a LOT longer.

I have what I need now and am no longer following this thread.

[Melba23]

vmguy,

You may not be following this thread any longer (although I wonder why not as you have raised an interesting point) but I will reply to a possible wider audience.

I have never used the Opt Expand*Strings option (as I prefer to concatenate to prevent the very type of confusion amply evidenced in this thread) but looking at the Help file I agree that the example could be amended to better explain the requirement to double up the leading $/@ in a variable/macro name - I will add a further example: "The value of $$var1 is $var1$" to hopefully prevent future confusion.

On a wider note, if you feel that there are several places in the Help file where it does not match the implementation, why not use the Bug Tracker (the link is in the header menu) to tell us about it so that we can amend it. We are quite prepared to do this as we want the Help file to be as accurate as possible, but we are a small team and rely a lot on others to tell us when amendments are necessary.

And AutoIt is, and will remain, closed source until Jon decides otherwise so you will just have to "rigorously test everything" - or you could post in the forum and ask as you got a correct solution to your "problem" pretty quickly this time.

M23

 

[vmguy]

@M23 ... my excuse is that I'm old too.
I have to choose wisely how I spend my remaining hours on the planet.
Debating design decisions is not my favorite activity.

I agree  I could use Bug Tracker.  Before I report bugs, I  want to be sure it is a bug.

My intention is to USE AutoIt as it stands.  My project has now stalled because things
aren't acting the way I  expect.  I am an ex-WinBatch user and enjoyed the product
because their "Clairvoyant Support Staff" eliminated the need for public debate to be understood.

Unlike Jon, I wasn't using "compiled Winbatch scripts" ... I had the source and never experienced a problem that wasn't solved instantly.

--Cheers