vmguy

Environment related bugs?

9 posts in this topic

#1 ·  Posted (edited)

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 @ComSpeccmd 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 by vmguy

Share this post


Link to post
Share on other sites



#2 ·  Posted

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

 

1 person likes this

Share this post


Link to post
Share on other sites

#3 ·  Posted (edited)

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 by vmguy

Share this post


Link to post
Share on other sites

#4 ·  Posted

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

 

Share this post


Link to post
Share on other sites

#5 ·  Posted (edited)

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 by vmguy

Share this post


Link to post
Share on other sites

#6 ·  Posted

11 hours ago, vmguy said:

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

Yes  :D  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  :)

 


 

Share this post


Link to post
Share on other sites

#7 ·  Posted

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.

Share this post


Link to post
Share on other sites

#8 ·  Posted

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

 


Any of my own code posted anywhere on the forum is available for use by others without any restriction of any kind._______My UDFs:

Spoiler

ArrayMultiColSort ---- Sort arrays on multiple columns
ChooseFileFolder ---- Single and multiple selections from specified path treeview listing
Date_Time_Convert -- Easily convert date/time formats, including the language used
ExtMsgBox --------- A highly customisable replacement for MsgBox
GUIExtender -------- Extend and retract multiple sections within a GUI
GUIFrame ---------- Subdivide GUIs into many adjustable frames
GUIListViewEx ------- Insert, delete, move, drag, sort, edit and colour ListView items
GUITreeViewEx ------ Check/clear parent and child checkboxes in a TreeView
Marquee ----------- Scrolling tickertape GUIs
NoFocusLines ------- Remove the dotted focus lines from buttons, sliders, radios and checkboxes
Notify ------------- Small notifications on the edge of the display
Scrollbars ----------Automatically sized scrollbars with a single command
StringSize ---------- Automatically size controls to fit text
Toast -------------- Small GUIs which pop out of the notification area

 

Share this post


Link to post
Share on other sites

#9 ·  Posted

@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
 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now