I am running an AutoIt script and that script calls another AutoIt file. How do I pass a variable value from my first script to the next?
You need to learn the scope concept of a variable (Dim, Global & Local variables).
From AutoItHelp
The difference between Dim, Local and Global is the scope in which they are created:
Dim = Local scope if the variable name doesn't already exist globally (in which case it reuses the global variable!) ;
Global = Forces creation of the variable in the Global scope ;
Local = Forces creation of the variable in the Local/Function scope.
Examples with two files: main.au3 and constantes.au3.
Content of constants.au3
#include-once
; Declaration of global variables
Global $name_application = "Foo"
Global $year = 2014
Content of main.au3
#include <constants.au3>
Func _foo()
ConsoleWrite("In function _foo() name_application is available and it's equals = "&$name_application&#CRLF)
Local $year2= 2014
EndFunc
ConsoleWrite("In main.au3 global variables are available"&#CRLF)
ConsoleWrite("For example, name_application = "&$name_application&#CRLF)
ConsoleWrite("But the local variable year2 isn't available here")
More information is here: http://www.autoitscript.fr/autoit3/docs/keywords/Dim.htm
Use command line interface in order to communicate between two files.
File 2 must be compiled.
File1.exe:
$ThisIsVariableFromFIle1 = "This is some text."
Run("File2.exe " & $ThisIsVariableFromFIle1)
File2.exe:
MsgBox(0,"This is the whole commandline I got", $CmdLineRaw)
MsgBox(0,"This is part one", $CmdLine[1]); This
MsgBox(0,"This is part two", $CmdLine[2]); is
MsgBox(0,"This is part three", $CmdLine[3]); some
Related
Here is my example, I need to set values to the environment variable as follows
I have already known variable called 'ponumberA', is it possible to set that value to environment variable using 'pm.environment.set' function.
(((var ponumberA="A1234";
pm.environment.set("ponumberxx",ponumberA);
var ponumberxxx=pm.variables.get("ponumberxx")
console.log ("Request PO # is " +ponumberxxx))))
https://learning.postman.com/docs/sending-requests/variables/
you can set variable and scope from pm object
pm.environment.set
pm.collectionVariables.set
pm.variables.set
pm.globals.set
you can use this variables in any session like url , body ,header etc as
{{variablename}}
example
pm.environment.set("myvar",2)
and in url
https://www.somewebsite.com?id={{myvar}}
On the frontend server I have a file I can read with:
if(!!process.env.SERVER) {
require("dotenv").config( { path: '/hw/.env', debug: true } )
console.log(process.env.myvar)
}
But how can I pass the vlue of process.env.myvar to the browser?
Thanks.
If you want to get some variables for all cases you can create an enviroment file with just .env as the name next to package.json in your project.
To get variables from that file you need to declare them first in the .env like this:
VUE_APP_MYVAR = 'myvar'
In your app you can use it like this:
process.env.VUE_APP_MYVAR
If you need some variables depending on the process, respectively for your enviroment, your myvar can't be called with process.env.SERVER. If SERVER is the process, you need a .env.server file next to your package.json.
You can then, again, declare myvar in .env.server like this:
VUE_APP_MYVAR = 'myvar'
To get process.env.VUE_APP_MYVAR this time you have to ensure, that you build or serve your enviroment named server. Else, your app trying to get process.env.VUE_APP_MYVAR with the process you used.
For Example: If you have .env.development and .env.server, both can contain VUE_APP_MYVAR = 'myvar' with different assigned values. Which one is picked depends on the enviroment you build or serve.
For more information, see the docs: Modes and Environment Variables
#Modes
I am new to SSIS . I am trying to use Script Task to get the last modified date and create date of a file. I have declared two variables to read the file path and file name (File_Path,Filename) in my script task as variables with scope as package and datatype as string.
I want to store the create date and modified date to two diff output variables(Create_Date,Last_Updated) with datatype as Datetime.
my code for the script is as follows
FileInfo fileInfo = new FileInfo(Path.Combine(Dts.Variables["File_Path"].Value.ToString(), Dts.Variables["Filename"].Value.ToString()));
if (fileInfo.Exists)
{
// Get file creation date
Dts.Variables["Create_Date"].Value = fileInfo.CreationTime;
// Get last modified date
Dts.Variables["Last_Updated"].Value = fileInfo.LastWriteTime;
}
else
{
Dts.Events.FireWarning(1, Dts.Variables["System::TaskName"].Value.ToString()
, string.Format("File '{0}' does not exist", fileInfo.FullName)
, "", 0);
}```
SSIS has a Design time and a Run time interface.
Variables are created in the Design time space. There you assign data type and a value. There is an explicit Variable's window that you do all of this with.
During run time, the Variables window will still be visible but the values there are not the run-time value. It's just a reference for what the package was initialized with. The actual values of SSIS variables are to be found in the debug windows. I favor the Locals window (Ctrl+Alt+V, L)
From there, expand the Variables node
You can also add explicit logging into your Script tasks. This little bit will enumerate through all the variables you selected for readonly or read/write access and pop off their name and value into the run log. If you're running in Visual Studio, it will show up in the Results tab or the Output window (great place to copy errors for further research or asking on forums). If you're running from the server, these will show in the SSISDB.catalog.operation_messages view (unless you picked an incompatible logging mode)
bool fireAgain = false;
string message = "{0}::{1} : {2}";
foreach (var item in Dts.Variables)
{
Dts.Events.FireInformation(0, "SCR Echo Back", string.Format(message, item.Namespace, item.Name, item.Value), string.Empty, 0, ref fireAgain);
}
I'm using workspaces in terraform to separate environments at runtime, so that I can separate deployments using a different configs.
However, I'm trying to figure out how to set CLI variables.
my variables.tf:
locals {
environment = "${terraform.workspace}"
lambda_vars = {
deploy_version = "0.1"
deploy_name = "deployment"
deploy_secret_1 = "somesupersecretsecret"
}
}
These variables are used throughout my config.
I'm trying to set new variables using the CLI, but it doesnt work, and I can't seem to find any reference to how to achieve this. I've tried:
terraform apply -var 'local.lambda_vars={ deploy_secret_1 = "somesupersecretsecret1" }'
I feel like I'm going about this the wrong way.
Can anyone help?
If you want to be able to configure the variables then you should use actual variables instead of locals. Locals are a way of composing things so you avoid repeating yourself or can use interpolation. Variables don't allow for any interpolation at all.
So in your case you should declare separate variables for things you want to be able configure. If this is just the deploy_secret_1 then you can do this with something like the following:
variable "deploy_secret_1" {
default = "somesupersecretsecret"
}
locals {
environment = terraform.workspace
lambda_vars = {
deploy_version = "0.1"
deploy_name = "deployment"
deploy_secret_1 = var.deploy_secret_1
}
}
Now if you run the following command:
terraform apply -var 'deploy_secret_1=overriding-secret'
It should overwrite the deploy_secret_1 part but leave the rest as is. If you don't specify the deploy_secret_1 variable either by the command line, environment variables or a tfvars file then it will default to somesupersecretsecret. If you'd rather force it to be defined and error if you don't specify the variable then just omit the default argument to the variable declaration.
If you wanted to be able to override more things then you should declare more variables.
One question for you is here ;)
I have this function:
function Set-DbFile {
param(
[Parameter(ValueFromPipeline=$true)]
[System.IO.FileInfo[]]
$InputObject,
[Parameter(ValueFromPipelineByPropertyName=$true)]
[scriptblock]
$Properties
)
process {
$InputObject | % {
Write-Host `nInside. Storing $_.Name
$props = & $Properties
Write-Host ' properties for the file are: ' -nonew
write-Host ($props.GetEnumerator()| %{"{0}-{1}" -f $_.key,$_.Value})
}
}
}
Look at the $Properties. It should be evaluated for each file and then the file and the properties should be processed further.
Example how to use it might be:
Get-ChildItem c:\windows |
? { !$_.PsIsContainer } |
Set-DbFile -prop {
Write-Host Creating properties for $_.FullName
#{Name=$_.Name } # any other properties based on the file
}
When I copy & paste function Set-dbFile to command line and run the example snippet, everything is fine.
However, when I store the function in a module, import it and run the example, the $_ variable is empty. Does anybody know why? And how to solve it? (other solutions are welcome as well)
Results for function defined in a script/typed in commandline:
Inside. Storing adsvw.ini
Creating properties for C:\windows\adsvw.ini
properties for the file are: Name-adsvw.ini
Inside. Storing ARJ.PIF
Creating properties for C:\windows\ARJ.PIF
properties for the file are: Name-ARJ.PIF
....
Results for function defined in module:
Inside. Storing adsvw.ini
Creating properties for
properties for the file are: Name-
Inside. Storing ARJ.PIF
Creating properties for
properties for the file are: Name-
....
The problem here is down to scope hierarchy. If you define two functions like...
function F1{
$test="Hello"
F2
}
function F2{
$test
}
Then F2 will inherit the variable scope of F1 since it's called from F1's scope. If you define function F2 in a module and export the function the $test variable is not available since the module has it's own scope tree. See the Powershell Language Specification (Section 3.5.6):
In your case the current node variable is defined in the local scope and hence it will not survive into the module scope since it's in a different tree with a different scope root (apart from global variables).
To quote the text on the GetNewClosure() method in the Powershell Language Specification (Section 4.3.7):
Retrieves a script block that is bound
to a module.Any local variables that
are in the context of the caller will
be copied into the module.
...hence GetNewClosure() works a treat since it bridges the local scope/module divide. I hope this helps.
Looks like GetNewClosure() is as good a work around as any, but it changes the way the script block sees those variables. Passing $_ to the scriptblock as an argument works, too.
It has nothing to do with normal scope issues (e.g., global vs local), but it appears like that at first. Here's my very simplified reproduction and some explanation following:
script.ps1 for normal dot-sourcing:
function test-script([scriptblock]$myscript){
$message = "inside"
&{write-host "`$message from $message"}
&$myscript
}
Module\MyTest\MyTest.psm1 for importing:
function test-module([scriptblock]$myscript){
$message = "inside"
&{write-host "`$message from $message"}
&$myscript
}
function test-module-with-closure([scriptblock]$myscript){
$message = "inside"
&{write-host "`$message from $message"}
&$myscript.getnewclosure()
}
Calls and output:
» . .\script.ps1
» import-module mytest
» $message = "outside"
» $block = {write-host "`$message from $message (inside?)"}
» test-script $block
$message from inside
$message from inside (inside?)
» test-module $block
$message from inside
$message from outside (inside?)
» test-module-with-closure $block
$message from inside
$message from inside (inside?)
So I started hunting around since this piqued my curiosity, and I found a few interesting things.
This Q&A, which also features a link to this bug report is pretty much the exact same topic, as are some other blog articles I ran across. But while it was reported as a bug, I disagree.
The about_Scopes page has this to say (w:
...
Restricting Without Scope
A few Windows PowerShell concepts are similar to scope or interact with
scope. These concepts may be confused with scope or the behavior of scope.
Sessions, modules, and nested prompts are self-contained environments,
but they are not child scopes of the global scope in the session.
...
Modules:
...
The privacy of a module behaves like a scope, but adding a module
to a session does not change the scope. And, the module does not have
its own scope, although the scripts in the module, like all Windows
PowerShell scripts, do have their own scope.
Now I understand the behavior, but it was the above and a few more experiments that led me to it:
If we change $message in the scriptblock to $local:message then all 3 tests have a blank space, because $message is not defined in the scriptblock's local scope.
If we use $global:message, all 3 tests print outside.
If we use $script:message, the first 2 tests print outside and the last prints inside.
Then I also read this in about_Scopes:
Numbered Scopes:
You can refer to scopes by name or by a number that
describes the relative position of one scope to another.
Scope 0 represents the current, or local, scope. Scope 1
indicates the immediate parent scope. Scope 2 indicates the
parent of the parent scope, and so on. Numbered scopes
are useful if you have created many recursive
scopes.
If we use $((get-variable -name message -scope 1).value) in order to attempt getting the value from the immediate parent scope, what happens? We still get outside rather than inside.
At this point it was clear enough to me that sessions and modules have their own declaration scope or context of sorts, at least for script blocks. The script blocks act like anonymous functions in the environment in which they're declared until you call GetNewClosure() on them, at which point they internalize copies of the variables they reference of the same name in the scope where GetNewClosure() was called (using locals first, up to globals). A quick demonstration:
$message = 'first message'
$sb = {write-host $message}
&$sb
#output: first message
$message = 'second message'
&$sb
#output: second message
$sb = $sb.getnewclosure()
$message = 'third message'
&$sb
#output: second message
I hope this helps.
Addendum: Regarding design.
JasonMArcher's comment made me think about a design issue with the scriptblock being passed into the module. In the code of your question, even if you use the GetNewClosure() workaround, you have to know the name of the variable(s) where the scriptblock will be executed in order for it to work.
On the other hand, if you used parameters to the scriptblock and passed $_ to it as an argument, the scriptblock does not need to know the variable name, it only needs to know that an argument of a particular type will be passed. So your module would use $props = & $Properties $_ instead of $props = & $Properties.GetNewClosure(), and your scriptblock would look more like this:
{ (param [System.IO.FileInfo]$fileinfo)
Write-Host Creating properties for $fileinfo.FullName
#{Name=$fileinfo.Name } # any other properties based on the file
}
See CosmosKey's answer for further clarification.
I believe you need to call getnewclosure() on that script block before you run it. Called from a script file or module, script blocks are evaluated at compile time. When you work from the console, there is no "compile time". It's evaluated at run time, so it behaves differenly there than when it's in the module.