Sign in to follow this  
Followers 0
spiderkayak

variables

12 posts in this topic

I need passing variables the script a other script

script1.exe ------> script2.exe

Example:

script1

EnvSet("PATH", "\\"&$server2&"\nscap\Temp\")

$VAR = EnvGet("PATH")

script2

$file2 = FileOpen("" &$VAR& "servers.csv", 1)

$VAR it belongs to script1

I have treated but it does not run

I need help !!!!

Share this post


Link to post
Share on other sites



I need passing variables the script a other script

script1.exe ------> script2.exe

Example:

script1

EnvSet("PATH", "\\"&$server2&"\nscap\Temp\")

$VAR = EnvGet("PATH")

script2

$file2 = FileOpen("" &$VAR& "servers.csv", 1)

$VAR it belongs to script1

I have treated but it does not run

I need help !!!!

<{POST_SNAPBACK}>

command line parameters are the way to go, or you could use an external file or registry setting...

1100111 00001011101111 00011101101111 00010111100100 00001111110100 00110111110010 00101101111001 0011100i didn't make up this form of encryption, but i like it.credit to the lvl 6 challenge on arcanum.co.nz

Share this post


Link to post
Share on other sites

when creeo a file in script1 and I read it from script2 does not work, can indicate to me like doing it

command line parameters are the way to go, or you could use an external file or registry setting...

<{POST_SNAPBACK}>

Share this post


Link to post
Share on other sites

when creeo a file in script1 and I read it from script2 does not work, can indicate to me like doing it

<{POST_SNAPBACK}>

You need to call the EnvGet function in the second script, buddy, something like this (compile the second script before testing):

; Script 1 - ENVSET.AU3
EnvSet("OURPATH", "\\bugjaw\sandbender\slackwire")
Run(@ScriptDir & "\envget.exe")

; Script 2 - ENVGET.AU3
$foo = EnvGet("OURPATH")
MsgBox(0, "Debug", $foo)

Be careful what name you use for your environment variable, PATH is already used by Windows...


Yes yes yes, there it was. Youth must go, ah yes. But youth is only being in a way like it might be an animal. No, it is not just being an animal so much as being like one of these malenky toys you viddy being sold in the streets, like little chellovecks made out of tin and with a spring inside and then a winding handle on the outside and you wind it up grrr grrr grrr and off it itties, like walking, O my brothers. But it itties in a straight line and bangs straight into things bang bang and it cannot help what it is doing. Being young is like being like one of these malenky machines.

Share this post


Link to post
Share on other sites

IMO you should use commandline since its cleaner and cant conflict with windows ;)

<{POST_SNAPBACK}>

agreed. that's always my first suggestion, especially if the scripts are running concurrently. if you want two scripts to use the same file, make sure you close the file in the calling script before you attempt to open it in the receiving script. or you may want to take the easy out you can just use the registry to pass values back and forth.

1100111 00001011101111 00011101101111 00010111100100 00001111110100 00110111110010 00101101111001 0011100i didn't make up this form of encryption, but i like it.credit to the lvl 6 challenge on arcanum.co.nz

Share this post


Link to post
Share on other sites

agreed.  that's always my first suggestion, especially if the scripts are running concurrently.  if you want two scripts to use the same file, make sure you close the file in the calling script before you attempt to open it in the receiving script.  or you may want to take the easy out you can just use the registry to pass values back and forth.

<{POST_SNAPBACK}>

*shrug*

Passing a path with the command line leads to the possiblilty of it getting mangled if there's a space in the path, and writing to the registry assumes that the user has rights to do so, knows an appropriate place to put it, and will clean it up after it's used so that it won't appear as a spurious stale value the next time the script is run (which may still happen in the case of an error).

Setting an environment variable is volatile, it won't matter if there are spaces, and was after all what the user asked for help with... ;)


Yes yes yes, there it was. Youth must go, ah yes. But youth is only being in a way like it might be an animal. No, it is not just being an animal so much as being like one of these malenky toys you viddy being sold in the streets, like little chellovecks made out of tin and with a spring inside and then a winding handle on the outside and you wind it up grrr grrr grrr and off it itties, like walking, O my brothers. But it itties in a straight line and bangs straight into things bang bang and it cannot help what it is doing. Being young is like being like one of these malenky machines.

Share this post


Link to post
Share on other sites

You need to call the EnvGet function in the second script, buddy, something like this (compile the second script before testing):

; Script 1 - ENVSET.AU3
EnvSet("OURPATH", "\\bugjaw\sandbender\slackwire")
Run(@ScriptDir & "\envget.exe")

; Script 2 - ENVGET.AU3
$foo = EnvGet("OURPATH")
MsgBox(0, "Debug", $foo)

Be careful what name you use for your environment variable, PATH is already used by Windows...

<{POST_SNAPBACK}>

Using Dave's example, try this:

Script 1

$VAR = EnvSet("PATH", "\\"&$server2&"\nscap\Temp\")
Run(@ScriptDir & "\envget.exe" & "" & $VAR)

Script 2

$VAR = EnvGet("PATH")
$file2 = FileOpen("" &$VAR& "servers.csv", 1)

Common sense plays a role in the basics of understanding AutoIt... If you're lacking in that, do us all a favor, and step away from the computer.

Share this post


Link to post
Share on other sites

There are many ways to pass variables between programs. If you use the cmdline, and have to pass dir names, try FileGetShortName() before sending it...


Writing AutoIt scripts since
_DateAdd("d", -2, _NowCalcDate())

Share this post


Link to post
Share on other sites

The above examples will not work unless EnvUpdate() is used after EnvSet() to refresh the Environment Variables, else a system reboot would be required to use the new Environmental Variables.

;)

Share this post


Link to post
Share on other sites

Let's try this again (First post deleted because the information appeared wrong).

EnvUpdate() is irrelevant to causing environment variables to be updated unless writing the variables to the registry. If writing the variables to the registry (to make them global variables), then a WM_SETTINGCHANGE is necessary to force Window's to reload those variables. Otherwise, EnvUpdate() has no correlation between EnvSet().

Share this post


Link to post
Share on other sites

The above examples will not work unless EnvUpdate() is used after EnvSet() to refresh the Environment Variables, else a system reboot would be required to use the new Environmental Variables.

;)

<{POST_SNAPBACK}>

I've never used EnvUpdate(), and have quite successfully used passing the variable between executibles using EnvSet() and EnvGet().

So in essence "will not work", is "not correct".


Common sense plays a role in the basics of understanding AutoIt... If you're lacking in that, do us all a favor, and step away from the computer.

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
Sign in to follow this  
Followers 0