I would like to have a function to run different ScriptBlocks. So, I need to use my Scriptblock as the parameter of the function. It does not work.
For example. This function returns the ScriptBlock as a string.
function Run_Scriptblock($SB) {
return $SB
}
These are the outputs from my tries:
# 1st try
Run_Scriptblock {systeminfo}
>> systeminfo
# 2nd try
Run_Scriptblock systeminfo
>> systeminfo
# 3rd try
Run_Scriptblock [scriptblock]systeminfo
>> [scriptblock]systeminfo
# 4th try
$Command = [scriptblock]{systeminfo}
Run_Scriptblock $Command
>> [scriptblock]systeminfo
# 5th try
[scriptblock]$Command = {systeminfo}
Run_Scriptblock $Command
>> systeminfo
If you want a function to run a scriptblock, you need to actually invoke or call that scriptblock, i.e.
function Run_Scriptblock($SB) {
$SB.Invoke()
}
or
function Run_Scriptblock($SB) {
& $SB
}
Otherwise the function will just return the scriptblock definition in string form. The return keyword is not needed, since PowerShell functions return all non-captured output by default.
The function would be called like this:
Run_Scriptblock {systeminfo}
As a side note, I would recommend you consider naming your function following PowerShell conventions (<Verb>-<Noun> with an approved verb), e.g.
function Invoke-Scriptblock($SB) {
...
}
Related
I have this code in my $profile in PS version 5:
function af_ {
Get-ChildItem function: | findstr.exe $args
if (! $args) {
return "nothing"
}
}
Calling e.g.
af_ tgit
Return:
Function tgit 0.7.3 posh-git
Calling
af_
Output:
FINDSTR: Syntaxfehler
nothing
Two questions:
How can I check if $args is not empty without "Syntaxfehler" (this is german..)?
Can I improve my idea to get the defnition of a custom function, as would be
declare -f $function
in Bash. It shows the definition which seems not possible in PS. I have to process the function: device and then look for the "Definition" output.
You get the syntax error because you call findstr.exe with the empty argument before checking it. Reversing the order should do it:
function af_ {
if (! $args) {
return "nothing"
}
Get-ChildItem function: | findstr.exe $args
}
As for your second question you can use Get-Command to get the command and it's definition:
(Get-Command af_).Definition
Say I'm passing a function as a parameter, is there a way to find out the name of the passed function through introspection in powershell? Or do I just have to pass it along with the rest of the parameters?
(without calling the function in question)
The linked question tries to pass a function by name, as a string, in which case the answer is obvious: the argument itself is the function name.
In case a script block is passed instead, you can use the following technique:
function get-ScriptBlockCommandName {
param(
[scriptblock] $ScriptBlock,
[switch] $Expand
)
# Using the script block's AST, extract the first command name / path token.
$commandName = $ScriptBlock.Ast.EndBlock.
Statements[0].PipelineElements.CommandElements[0].Extent.Text
# Expand (interpolate) the raw name, if requested.
if ($Expand) {
$commandName = $ExecutionContext.InvokeCommand.ExpandString($commandName)
}
# Remove outer quoting, if present.
if ($commandName -match '^([''"])(.+)\1$') {
$commandName = $Matches[2]
if ($Matches[1] -eq "'") { $commandName = $commandName -replace "''", "'" }
}
# Output
$commandName
}
The function returns the (first) command name / path that is called from inside the script block.
Caveats:
An error will occur if you pass an expression (e.g., 1 + 2) as the first statement inside the script block.
Only the first command is analyzed (and its command name / path returned), whereas there is no limit to how many statements you can place inside a script block.
By default, if the command name / path is constructed from variables / other commands, these are not expanded (interpolated), given that doing so can result in execution of commands; to opt into expansion, use the -Expand switch.
Example calls:
PS> get-ScriptBlockCommandName { foo -bar baz -more stuff }
foo
This also works with quoted names / paths (note how & must then be used to invoke the command):
PS> get-ScriptBlockCommandName { & '/dir name/foo' -bar baz -more stuff }
/dir name/foo
However, to avoid potentially unwanted execution of commands, the command name / path is returned as-is, with variable references and subexpressions unexpanded.
You can opt to have these expanded by passing -Expand:
PS> get-ScriptBlockCommandName { & "$HOME/scripts/foo.ps1" -bar baz } -Expand
C:/Users/jdoe/scripts.ps1 # e.g.
I have a function that I should be able to call from any place in my powershell script.
The problem is that it doesn't identify the function in a script block.
In the following example I have the function getNumberFive which should return the number 5.
I want to be able to use this function inside a scriptblock when I start a new job and also in the end of the script.
Expected result:
Write the number 15 to the file "C:\tmp\result.txt"
Write to the console: "I like the number 5"
In reality:
Write the number 10 to the file "C:\tmp\result.txt"
Write to the console: "I like the number 5"
I can workaround this issue by defining the same function inside the scriptblock but then I will duplicate the function and this is not a good programming.
Another way is to define:
$func = {
function getNumberFive(){
return 5
}
}
$scriptBlock = {
Function printSum(){
$number = getNumberFive
$newNumber = 10 + $number # => $newNumber should be 15
$newNumber >> "C:\tmp\result.txt"
}
}
Start-Job -ScriptBlock $scriptBlock -InitializationScript $func
But in this case I won't be able to call $five = getNumberFive.
I read number of methods but I didn't understand how exactly to use them:
CALLING A POWERSHELL FUNCTION IN A START-JOB SCRIPT BLOCK WHEN IT’S DEFINED IN THE SAME SCRIPT
How to pass a named function as a parameter (scriptblock)
https://social.technet.microsoft.com/Forums/ie/en-US/485df2df-1577-4770-9db9-a9c5627dd04a/how-to-pass-a-function-to-a-scriptblock?forum=winserverpowershell
PowerShell: Pass function as a parameter
Using Invoke-Command -ScriptBlock on a function with arguments
My script:
function getNumberFive(){
return 5
}
$scriptBlock = {
Function printSum(){
# $number = getNumberFive => DOESN'T WORK
# $number = Invoke-Expression ($(get-command getNumberFive) | Select -ExpandProperty Definition) => DOESN'T WORK AS EXPECTED
# $number = &(${function:getNumberFive}) => DOESN'T WORK AS EXPECTED
# $number = &(Get-Item function:getNumberFive) => DOESN'T WORK AS EXPECTED
$newNumber = 10 + $number # => $newNumber should be 15
$newNumber >> "C:\tmp\result.txt"
}
printSum
}
Start-Job -ScriptBlock $scriptBlock
$five = getNumberFive
Write-Host "I like the number"$five
Get-Job | Wait-Job
Get-Job | Stop-Job
Get-Job | Remove-Job
When you pass a scriptblock to start-job (or invoke-expression) the PowerShell instance that executes that scriptblock only has access to that scriptblock, anything that script block loads, and anything that already exists in the PowerShell instance.
Other parts of your script are not included. (For functions locally defined in your script to be available from other, possibly remote, instances of PowerShell the whole script – not just the scriptblock – and any dependencies would need to be accessible from the other instance.)
You could refactor the code you want in both places into a module which the script block loads as well as the job creating script.
When using jobs you are executing code in another process: like any remote operation the remote executing is a separate environment.
You can do like this:
function getNumberFive(){
return 5
}
$a={
Function printSum($number){
$newNumber = 10 + $number # => $newNumber should be 15
$newNumber >> "D:\result.txt"
}
}
$scriptBlock = {
param($number)
printSum -number $number
}
$five = getNumberFive
Write-Host "I like the number"$five
Start-Job -InitializationScript $a -ScriptBlock $scriptBlock -ArgumentList $five
There is a switch name -InitializationScript in Start-job where you can keep your initialization code like a function. Wrap it in a scriptblock and simply call it from the main scriptblock.
Hope it helps.
I have this code in one of my PowerShell scripts:
function callCommandWithArguments([String] $arg1, [String] $arg2)
{
[string]$pathToCommand = "C:\command.exe";
[Array]$arguments = "anArg", "-other", "$arg2", "$arg1";
# the real code is
# & $pathToCommand $arguments;
# but was not working, so I change it to debug
Write-Host $pathToCommand $arguments;
}
callCommandWithArguments("1", "2");
As the arguments order is changed in the $arguments array, I would expect this output:
C:\command.exe anArg -other 2 1
But instead I receive a strange:
C:\command.exe anArg -other 1 2
Am I missing something obvious?
try call your function like this:
callCommandWithArguments "1" "2"
In powershell you pass arguments to function without () and just separated by space.
In your code you are passsing a single argument array of type object[]
A PowerShell ScriptBlock is not a lexical closure as it does not close over the variables referenced in its declaring environment. Instead it seems to leverage dynamic scope and free variables which are bound at run time in a lambda expression.
function Get-Block {
$b = "PowerShell"
$value = {"Hello $b"}
return $value
}
$block = Get-Block
& $block
# Hello
# PowerShell is not written as it is not defined in the scope
# in which the block was executed.
function foo {
$value = 5
function bar {
return $value
}
return bar
}
foo
# 5
# 5 is written $value existed during the evaluation of the bar function
# it is my understanding that a function is a named scriptblock
# which is also registered to function:
Calling GetNewClosure() on a ScriptBlock returns a new ScriptBlock which closes over the variables referenced. But this is very limited in scope and ability.
What is a ScriptBlock's classification?
Per the docs, a scriptblock is a "precompiled block of script text." So by default you just a pre-parsed block of script, no more, no less. Executing it creates a child scope, but beyond that it's as if you pasted the code inline. So the most appropriate term would simply be "readonly source code."
Calling GetNewClosure bolts on a dynamically generated Module which basically carries a snapshot of all the variables in the caller's scope at the time of calling GetNewClosure. It is not a real closure, simply a snapshot copy of variables. The scriptblock itself is still just source code, and variable binding does not occur until it is invoked. You can add/remove/edit variables in the attached Module as you wish.
function GetSB
{
$funcVar = 'initial copy'
{"FuncVar is $funcVar"}.GetNewClosure()
$funcVar = 'updated value' # no effect, snapshot is taken when GetNewClosure is called
}
$sb = GetSB
& $sb # FuncVar is initial copy
$funcVar = 'outside'
& $sb # FuncVar is initial copy
$sb.Module.SessionState.PSVariable.Remove('funcVar')
& $sb # FuncVar is outside
A PowerShell ScriptBlock is equivalent to a first-class, anonymous function. Most of the confusion I've seen is not with ScriptBlocks, but with the function keyword.
PowerShell does support function closures, however the function keyword does not.
Examples
Function:
PS> function Hello {
>> param ([string] $thing)
>>
>> return ("Hello " + $thing)
>> }
PS> Hello "World"
"Hello World"
ScriptBlock:
PS> $HelloSB = {
>> param ([string] $thing)
>>
>> return ("Hello " + $thing)
>> }
PS> & $HelloSB "World"
"Hello World"
PS> $HelloRef = $HelloSB
PS> & $HelloRef "Universe"
"Hello Universe"
Closure:
PS> $Greeter = {
>> param ([string] $Greeting)
>>
>> return ( {
>> param ([string] $thing)
>>
>> return ($Greeting + " " + $thing)
>> }.GetNewClosure() )
>> }
PS> $Ahoy = (& $Greeter "Ahoy")
PS> & $Ahoy "World"
"Ahoy World"
PS> $Hola = (& $Greeter "Hola")
PS> & $Hola "Mundo"
"Hola Mundo"
Although you can get around the limitation of the function keyword with the "Set-Item" cmdlet:
PS> function Greeter = { ... } # ✕ Error
PS> function Greeter { ... }.GetNewClosure() # ✕ Error
PS> Set-Item -Path "Function:Greeter" -Value $Greeter # (defined above) ✓ OK
PS> $Hola = Greeter "Hola"
PS> & $Hola "Mundo"
"Hola Mundo"
The Value parameter of the "Set-Item" cmdlet can be any ScriptBlock, even one returned by another function. (The "Greeter" function, for example, returns a closure, as shown above.)
PS> Set-Item -Path "Function:Aloha" -Value (Greeter "Aloha")
PS> Aloha "World"
"Aloha World"
Two other important points:
PowerShell uses dynamic scoping, not lexical scoping.
A lexical closure is closed on its source-code environment, whereas a dynamic closure is closed based on the active/dynamic environment that exists when GetNewClosure() is called. (Which is more appropriate for a scripting language.)
PowerShell may have "functions" and "return" statements, but actually its input/output is based on streams and piping. Anything written out of a ScriptBlock with the "Write-Output" or "write" cmdlet will be returned.