PowerShell “=” not a recognised cmdlet error











up vote
1
down vote

favorite












Further to the response given here: PowerShell Enter Session find path bug, I've hit another wall in my script that I can't work around. The below script returns the error:




The term '=' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.




$sb = [ScriptBlock]::Create(@"
$Acl = (Get-Item -path D:Websites$Sitename).GetAccessControl('Access')
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$Acl.SetAccessRule($Ar)
Set-Acl -path $Path -AclObject $Acl
"@)

Invoke-Command -Session $Session -ScriptBlock $sb


I can create the script block variable ($sb), but when I invoke it, I get the error. I have narrowed it down to the setting of the $Acl variable, and tried rewriting various ways with no luck. What am I missing?










share|improve this question




















  • 1




    Change @""@ to @''@ (single-quoted here strings rather than double-quoted)
    – Mathias R. Jessen
    Sep 5 '17 at 13:56










  • That won't work as the $sitename variable is being passed into the script block, so needs to be expanded? I need the $acl, $ar $acl and $path variables to be handled as variables, but have the $sitename variable expanded
    – Karl
    Sep 5 '17 at 14:03










  • I've updated my answer to accommodate that.
    – Mathias R. Jessen
    Sep 5 '17 at 14:07















up vote
1
down vote

favorite












Further to the response given here: PowerShell Enter Session find path bug, I've hit another wall in my script that I can't work around. The below script returns the error:




The term '=' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.




$sb = [ScriptBlock]::Create(@"
$Acl = (Get-Item -path D:Websites$Sitename).GetAccessControl('Access')
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$Acl.SetAccessRule($Ar)
Set-Acl -path $Path -AclObject $Acl
"@)

Invoke-Command -Session $Session -ScriptBlock $sb


I can create the script block variable ($sb), but when I invoke it, I get the error. I have narrowed it down to the setting of the $Acl variable, and tried rewriting various ways with no luck. What am I missing?










share|improve this question




















  • 1




    Change @""@ to @''@ (single-quoted here strings rather than double-quoted)
    – Mathias R. Jessen
    Sep 5 '17 at 13:56










  • That won't work as the $sitename variable is being passed into the script block, so needs to be expanded? I need the $acl, $ar $acl and $path variables to be handled as variables, but have the $sitename variable expanded
    – Karl
    Sep 5 '17 at 14:03










  • I've updated my answer to accommodate that.
    – Mathias R. Jessen
    Sep 5 '17 at 14:07













up vote
1
down vote

favorite









up vote
1
down vote

favorite











Further to the response given here: PowerShell Enter Session find path bug, I've hit another wall in my script that I can't work around. The below script returns the error:




The term '=' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.




$sb = [ScriptBlock]::Create(@"
$Acl = (Get-Item -path D:Websites$Sitename).GetAccessControl('Access')
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$Acl.SetAccessRule($Ar)
Set-Acl -path $Path -AclObject $Acl
"@)

Invoke-Command -Session $Session -ScriptBlock $sb


I can create the script block variable ($sb), but when I invoke it, I get the error. I have narrowed it down to the setting of the $Acl variable, and tried rewriting various ways with no luck. What am I missing?










share|improve this question















Further to the response given here: PowerShell Enter Session find path bug, I've hit another wall in my script that I can't work around. The below script returns the error:




The term '=' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.




$sb = [ScriptBlock]::Create(@"
$Acl = (Get-Item -path D:Websites$Sitename).GetAccessControl('Access')
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$Acl.SetAccessRule($Ar)
Set-Acl -path $Path -AclObject $Acl
"@)

Invoke-Command -Session $Session -ScriptBlock $sb


I can create the script block variable ($sb), but when I invoke it, I get the error. I have narrowed it down to the setting of the $Acl variable, and tried rewriting various ways with no luck. What am I missing?







powershell invoke-command scriptblock






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 19 at 7:13









Peter Mortensen

13.3k1983111




13.3k1983111










asked Sep 5 '17 at 13:54









Karl

275




275








  • 1




    Change @""@ to @''@ (single-quoted here strings rather than double-quoted)
    – Mathias R. Jessen
    Sep 5 '17 at 13:56










  • That won't work as the $sitename variable is being passed into the script block, so needs to be expanded? I need the $acl, $ar $acl and $path variables to be handled as variables, but have the $sitename variable expanded
    – Karl
    Sep 5 '17 at 14:03










  • I've updated my answer to accommodate that.
    – Mathias R. Jessen
    Sep 5 '17 at 14:07














  • 1




    Change @""@ to @''@ (single-quoted here strings rather than double-quoted)
    – Mathias R. Jessen
    Sep 5 '17 at 13:56










  • That won't work as the $sitename variable is being passed into the script block, so needs to be expanded? I need the $acl, $ar $acl and $path variables to be handled as variables, but have the $sitename variable expanded
    – Karl
    Sep 5 '17 at 14:03










  • I've updated my answer to accommodate that.
    – Mathias R. Jessen
    Sep 5 '17 at 14:07








1




1




Change @""@ to @''@ (single-quoted here strings rather than double-quoted)
– Mathias R. Jessen
Sep 5 '17 at 13:56




Change @""@ to @''@ (single-quoted here strings rather than double-quoted)
– Mathias R. Jessen
Sep 5 '17 at 13:56












That won't work as the $sitename variable is being passed into the script block, so needs to be expanded? I need the $acl, $ar $acl and $path variables to be handled as variables, but have the $sitename variable expanded
– Karl
Sep 5 '17 at 14:03




That won't work as the $sitename variable is being passed into the script block, so needs to be expanded? I need the $acl, $ar $acl and $path variables to be handled as variables, but have the $sitename variable expanded
– Karl
Sep 5 '17 at 14:03












I've updated my answer to accommodate that.
– Mathias R. Jessen
Sep 5 '17 at 14:07




I've updated my answer to accommodate that.
– Mathias R. Jessen
Sep 5 '17 at 14:07












1 Answer
1






active

oldest

votes

















up vote
2
down vote



accepted










When you use a double-quoted here-string, it behaves just like a regular double-quoted string - the parser will evaluate and expand any variable or sub-expression between the quotation marks.



Since the variables in the scriptblock definition doesn't already exist in the defining context, you end up with a scriptblock with the following definition:



 = (Get-Item -path D:Websites).GetAccessControl('Access')
= New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
.SetAccessRule()
Set-Acl -path -AclObject


As you can see, the first two statements start out with just a bare = as the first non-whitespace character, and this is the reason for the error you're seeing.



Switch to a single-quoted here-string instead:



$sb = [ScriptBlock]::Create(@'
$Acl = (Get-Item -path D:Websites$Sitename).GetAccessControl('Access')
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$Acl.SetAccessRule($Ar)
Set-Acl -path $Path -AclObject $Acl
'@)


If you need to pass in a variable value from the defining scope, I'd suggest either defining a param block in the scriptblock:



$sb = [ScriptBlock]::Create(@'
param($Sitename)
$Acl = (Get-Item -path D:Websites$Sitename).GetAccessControl('Access')
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$Acl.SetAccessRule($Ar)
Set-Acl -path $Path -AclObject $Acl
'@)
Invoke-Command -Session $Session -ScriptBlock $sb -ArgumentList $Sitename


or use the -f string format operator to replace it in the string before creating the scriptblock:



$sb = [ScriptBlock]::Create(@'
$Acl = (Get-Item -path D:Websites{0}).GetAccessControl('Access')
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$Acl.SetAccessRule($Ar)
Set-Acl -path $Path -AclObject $Acl
'@ -f $Sitename)




See the about_Quoting_Rules help topic for more information about quoting and variable expansion






share|improve this answer























  • That's worked perfectly, thank you very much. i wasn't aware of the -f switch
    – Karl
    Sep 5 '17 at 14:22






  • 2




    @Karl It's referred to as the format operator in case you google it in the future.
    – TheIncorrigible1
    Sep 5 '17 at 14:30











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f46056781%2fpowershell-not-a-recognised-cmdlet-error%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
2
down vote



accepted










When you use a double-quoted here-string, it behaves just like a regular double-quoted string - the parser will evaluate and expand any variable or sub-expression between the quotation marks.



Since the variables in the scriptblock definition doesn't already exist in the defining context, you end up with a scriptblock with the following definition:



 = (Get-Item -path D:Websites).GetAccessControl('Access')
= New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
.SetAccessRule()
Set-Acl -path -AclObject


As you can see, the first two statements start out with just a bare = as the first non-whitespace character, and this is the reason for the error you're seeing.



Switch to a single-quoted here-string instead:



$sb = [ScriptBlock]::Create(@'
$Acl = (Get-Item -path D:Websites$Sitename).GetAccessControl('Access')
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$Acl.SetAccessRule($Ar)
Set-Acl -path $Path -AclObject $Acl
'@)


If you need to pass in a variable value from the defining scope, I'd suggest either defining a param block in the scriptblock:



$sb = [ScriptBlock]::Create(@'
param($Sitename)
$Acl = (Get-Item -path D:Websites$Sitename).GetAccessControl('Access')
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$Acl.SetAccessRule($Ar)
Set-Acl -path $Path -AclObject $Acl
'@)
Invoke-Command -Session $Session -ScriptBlock $sb -ArgumentList $Sitename


or use the -f string format operator to replace it in the string before creating the scriptblock:



$sb = [ScriptBlock]::Create(@'
$Acl = (Get-Item -path D:Websites{0}).GetAccessControl('Access')
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$Acl.SetAccessRule($Ar)
Set-Acl -path $Path -AclObject $Acl
'@ -f $Sitename)




See the about_Quoting_Rules help topic for more information about quoting and variable expansion






share|improve this answer























  • That's worked perfectly, thank you very much. i wasn't aware of the -f switch
    – Karl
    Sep 5 '17 at 14:22






  • 2




    @Karl It's referred to as the format operator in case you google it in the future.
    – TheIncorrigible1
    Sep 5 '17 at 14:30















up vote
2
down vote



accepted










When you use a double-quoted here-string, it behaves just like a regular double-quoted string - the parser will evaluate and expand any variable or sub-expression between the quotation marks.



Since the variables in the scriptblock definition doesn't already exist in the defining context, you end up with a scriptblock with the following definition:



 = (Get-Item -path D:Websites).GetAccessControl('Access')
= New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
.SetAccessRule()
Set-Acl -path -AclObject


As you can see, the first two statements start out with just a bare = as the first non-whitespace character, and this is the reason for the error you're seeing.



Switch to a single-quoted here-string instead:



$sb = [ScriptBlock]::Create(@'
$Acl = (Get-Item -path D:Websites$Sitename).GetAccessControl('Access')
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$Acl.SetAccessRule($Ar)
Set-Acl -path $Path -AclObject $Acl
'@)


If you need to pass in a variable value from the defining scope, I'd suggest either defining a param block in the scriptblock:



$sb = [ScriptBlock]::Create(@'
param($Sitename)
$Acl = (Get-Item -path D:Websites$Sitename).GetAccessControl('Access')
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$Acl.SetAccessRule($Ar)
Set-Acl -path $Path -AclObject $Acl
'@)
Invoke-Command -Session $Session -ScriptBlock $sb -ArgumentList $Sitename


or use the -f string format operator to replace it in the string before creating the scriptblock:



$sb = [ScriptBlock]::Create(@'
$Acl = (Get-Item -path D:Websites{0}).GetAccessControl('Access')
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$Acl.SetAccessRule($Ar)
Set-Acl -path $Path -AclObject $Acl
'@ -f $Sitename)




See the about_Quoting_Rules help topic for more information about quoting and variable expansion






share|improve this answer























  • That's worked perfectly, thank you very much. i wasn't aware of the -f switch
    – Karl
    Sep 5 '17 at 14:22






  • 2




    @Karl It's referred to as the format operator in case you google it in the future.
    – TheIncorrigible1
    Sep 5 '17 at 14:30













up vote
2
down vote



accepted







up vote
2
down vote



accepted






When you use a double-quoted here-string, it behaves just like a regular double-quoted string - the parser will evaluate and expand any variable or sub-expression between the quotation marks.



Since the variables in the scriptblock definition doesn't already exist in the defining context, you end up with a scriptblock with the following definition:



 = (Get-Item -path D:Websites).GetAccessControl('Access')
= New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
.SetAccessRule()
Set-Acl -path -AclObject


As you can see, the first two statements start out with just a bare = as the first non-whitespace character, and this is the reason for the error you're seeing.



Switch to a single-quoted here-string instead:



$sb = [ScriptBlock]::Create(@'
$Acl = (Get-Item -path D:Websites$Sitename).GetAccessControl('Access')
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$Acl.SetAccessRule($Ar)
Set-Acl -path $Path -AclObject $Acl
'@)


If you need to pass in a variable value from the defining scope, I'd suggest either defining a param block in the scriptblock:



$sb = [ScriptBlock]::Create(@'
param($Sitename)
$Acl = (Get-Item -path D:Websites$Sitename).GetAccessControl('Access')
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$Acl.SetAccessRule($Ar)
Set-Acl -path $Path -AclObject $Acl
'@)
Invoke-Command -Session $Session -ScriptBlock $sb -ArgumentList $Sitename


or use the -f string format operator to replace it in the string before creating the scriptblock:



$sb = [ScriptBlock]::Create(@'
$Acl = (Get-Item -path D:Websites{0}).GetAccessControl('Access')
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$Acl.SetAccessRule($Ar)
Set-Acl -path $Path -AclObject $Acl
'@ -f $Sitename)




See the about_Quoting_Rules help topic for more information about quoting and variable expansion






share|improve this answer














When you use a double-quoted here-string, it behaves just like a regular double-quoted string - the parser will evaluate and expand any variable or sub-expression between the quotation marks.



Since the variables in the scriptblock definition doesn't already exist in the defining context, you end up with a scriptblock with the following definition:



 = (Get-Item -path D:Websites).GetAccessControl('Access')
= New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
.SetAccessRule()
Set-Acl -path -AclObject


As you can see, the first two statements start out with just a bare = as the first non-whitespace character, and this is the reason for the error you're seeing.



Switch to a single-quoted here-string instead:



$sb = [ScriptBlock]::Create(@'
$Acl = (Get-Item -path D:Websites$Sitename).GetAccessControl('Access')
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$Acl.SetAccessRule($Ar)
Set-Acl -path $Path -AclObject $Acl
'@)


If you need to pass in a variable value from the defining scope, I'd suggest either defining a param block in the scriptblock:



$sb = [ScriptBlock]::Create(@'
param($Sitename)
$Acl = (Get-Item -path D:Websites$Sitename).GetAccessControl('Access')
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$Acl.SetAccessRule($Ar)
Set-Acl -path $Path -AclObject $Acl
'@)
Invoke-Command -Session $Session -ScriptBlock $sb -ArgumentList $Sitename


or use the -f string format operator to replace it in the string before creating the scriptblock:



$sb = [ScriptBlock]::Create(@'
$Acl = (Get-Item -path D:Websites{0}).GetAccessControl('Access')
$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule('BUILTINIIS_IUSRS', 'Modify', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$Acl.SetAccessRule($Ar)
Set-Acl -path $Path -AclObject $Acl
'@ -f $Sitename)




See the about_Quoting_Rules help topic for more information about quoting and variable expansion







share|improve this answer














share|improve this answer



share|improve this answer








edited Sep 5 '17 at 14:07

























answered Sep 5 '17 at 14:01









Mathias R. Jessen

55.4k45399




55.4k45399












  • That's worked perfectly, thank you very much. i wasn't aware of the -f switch
    – Karl
    Sep 5 '17 at 14:22






  • 2




    @Karl It's referred to as the format operator in case you google it in the future.
    – TheIncorrigible1
    Sep 5 '17 at 14:30


















  • That's worked perfectly, thank you very much. i wasn't aware of the -f switch
    – Karl
    Sep 5 '17 at 14:22






  • 2




    @Karl It's referred to as the format operator in case you google it in the future.
    – TheIncorrigible1
    Sep 5 '17 at 14:30
















That's worked perfectly, thank you very much. i wasn't aware of the -f switch
– Karl
Sep 5 '17 at 14:22




That's worked perfectly, thank you very much. i wasn't aware of the -f switch
– Karl
Sep 5 '17 at 14:22




2




2




@Karl It's referred to as the format operator in case you google it in the future.
– TheIncorrigible1
Sep 5 '17 at 14:30




@Karl It's referred to as the format operator in case you google it in the future.
– TheIncorrigible1
Sep 5 '17 at 14:30


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f46056781%2fpowershell-not-a-recognised-cmdlet-error%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

If I really need a card on my start hand, how many mulligans make sense? [duplicate]

Alcedinidae

Can an atomic nucleus contain both particles and antiparticles? [duplicate]