invoke-command // Indent

Hi guys,

Little and easy question here about « invoke-command »

Is there other « stuff » that work like that indent wise ?
This work :

Invoke-command –computername xxxx –ScriptBlock {
Do stuff here

This doesn’t work :

Invoke-command –computername xxxx –ScriptBlock 
Do stuff here

Well, now i know for this one, but is there other cmdlet that behave this way ? is there a specifique reason for it ?

Thank you in advance :wink:

It’s all in how the parser works.

The parser needs to see the opening { right after the -ScriptBlock parameter, so it knows where the parameter value begins. But once you’re in the script block, you can do whatever you want until you hit the closing }. That’s true of all script blocks, like the one that follows an If statement.

Scripting language constructs have some exceptions in the parser, which is why you can open the script block on the following line. That’s there because it’s such a common coding practice, people would expect it.

Although this isn’t really about indentation, right? It’s about where you can legally place a carriage return within a command. You can also do it after a pipe character, since PowerShell will expect there to be another command. It’ll go looking for it on the next line, if needed. And there are a bunch of other places - inside hash tables, for example, within a here-string, and so on.

First thank you for your answer Don, didn’t expect « you » to answer this kind of question. :wink:

Second yeah, you’r right this is not really « indent » but i must admit i was short on word for this one, i’m not a dev nor English is my first language and i just didn’t know the proper word for it :wink:

I’m at a kind of a loss about your example with « if statement » : when i do use ISE, and press the « famous » ctrl+j i do get a proposition (powershell v5) which is :

 if ($x -gt $y)

And i have used this construction (right wording ?) without any flaw up till now.
As of now the only exception i found about the « { » starting point really is in the invoke-command cmdlet
But the things i use the most are mainly : if, foreach, function, switch, icm.
Maybe not deep enought to find the other one (hence my question about other exception :wink: )

As I said, the If statement, along with other scripting constructs like For and ForEach, have exceptions which permit the script block to begin on the following line. That’s because many developers prefer that formatting convention and expect it to work. But those are scripting constructs. Invoke-Command is not a scripting construct; it is a command, and you are providing it with parameters. The value for a parameter must always follow the parameter, separated by a space; it is never permissible to have a carriage return after the parameter name and before the value.

get-service -name

Would not be legal. Therefore,

Invoke-command -scriptblock
{ whatever }

Is also not legal. The parser simply was not programmed to deal with that, and so those commands would fail.

The big difference between the examples is that -ScriptBlock is a parameter on the Invoke-Command cmdlet and is expecting you to provide an argument in place. Think of it like…

$sb = { some code here }
Invoke-Command -ComputerName Server1 -ScriptBlock $sb

You can create the block inline without saving it into a variable first, but the argument must be provided in line. You could technically use a back tick to put it on the next line, if it really bothers you. In any case as Don explained it is not the same as If, Foreach, etc.

oh thank you, both.
I get it now, it simply dosen’t work because it’s part of the parameter so i will expect similar behaviour if i ever get in touch with another one “like that” :wink:
@stefan nah don’t worry it’s not bothering me the way you are putting it i don’t HAVE to get the “{” after a carriage return huhu.
what was bothering me was the “why” and i get it now, perfect :slight_smile: