Home Dashboard Directory Help

Reduce the need for line continuation use in PowerShell commands that span multiple lines by Kirk Munro



Sign in
to vote
Type: Suggestion
ID: 786717
Opened: 5/10/2013 8:07:12 AM
Access Restriction: Public


It is well known that the line continuation implementation is challenging (the fact that it doesn't work if there is anything after it, even just whitespace, causes problems for beginners; also, it doesn't help that it simply looks like a spec of dirt on the screen). Yet some of us find that commands are more readable when they span multiple lines, like this:

Do-Something `
    -Param value1 `
    -Param value2

Also, some of us use line continuance so that we can start a stage in a pipeline with the pipe symbol, like this:

Do-Something `
    | Do-SomethingWithIt `
    | Do-SomethingElse

Both of these syntaxes make for easy identification of commands that span multiple lines in structured documents.

With these syntaxes being desirable, and with the strong dislike for the backtick line continuance, why not just support these syntaxes without the line continuance character requirement? It would make scripts like this even easier to write, and if you could have comment lines in the middle (please do) it would allow for more detailed comments where desired. Plus, with support for comments in the middle you could play around with pipelines and parameters more easily by commenting/uncommenting various stages by simply commenting or uncommenting lines.
Sign in to post a comment.
Posted by Roman Kuzmin on 7/17/2013 at 4:01 AM
Personally I am rather happy with the backtick. But all the spaces after it followed by a new line should be ignored by the parser.
Posted by Trevor Sullivan on 5/13/2013 at 7:39 AM
My guess it that the back tick was specifically chosen, because it has little significance elsewhere. Look at regular expressions, for example. RegEx use a backslash as an escape character, which makes reading them harder than it already is, because the backslash and forward slash character is such a common one (eg. local filesystem paths, UNC paths, website URLs, etc.).

I agree that the back tick probably isn't the best character to use as an escape character, due to its small size, but I don't think that using a common character, such as the underscore (_), which is commonly use in filesystem paths, code comments, URLs, and other places, would be a better option.

As difficult as it is to see the back tick, I'm very glad that Microsoft chose an escape character that's practically used nowhere else.

The point that JrLd made is also very important. One of the attributes of PowerShell that makes it so incredibly attractive, is that anything that works at the interactive command prompt will also work inside of a script, and vice versa. It would be terribly destructive to see scripts behave differently from the interactive prompt, solely to accommodate the avoidance of the back tick character.
Posted by SteveRobbins on 5/12/2013 at 1:42 AM
I agree the back tick is difficult to spot. As a PowerShell newbie with no scripting background I find reading code spread across multiple lines better for my understanding. Code that spews along on one line off the screen and into the horizon may get the job done, but it's difficult to troubleshoot.
It would be very useful to have another character to replace the back tick that is easier to spot line continuation.
Posted by Bartek Bielawski on 5/11/2013 at 1:57 AM
Different line continuation character - why not. I hardly ever use backtick, you named all reasons "why". Supporting syntax like above *without* any character - I hope I won't see it, ever. JlRd and S.K. named all reasons why, so I won't repeat it.

Not sure why you say you need comments inside? You can have them already, and you can use them to break line as you wish too:
Do-Something <#
    I will do something cool!
#> -Param1 Value1 <#
    Value1 is best for Param1 in this scenario
#> -Param2 Value2 <#
    And that's obvious, right? :)

Same would work with pipeline too...
Posted by JlRd on 5/10/2013 at 7:28 PM
I have no love for the back tick operator. These recommendations make sense for script documents but how would this play at the shell command line. How would it know I want to execute a cmdlet with no params or a cmdlet with a line break and params to follow.

I wouldn't want to see a behavior difference between the two. I imagine with the wizardry of lexical analysis and parsing techniques anything would be possible. I like the VBScript semantics as mentioned below. The _ character has no current significance that I'm aware of in the language and it has history with this purpose.

Though not expressly mentioned in the original post I think a good reason for providing an alternate mechanism for the backtick is for presentation, both web and slide (i.e. PowerPoint). The "dead pixel" phenomenon as mentioned below is great. It is something that can impact teaching and learning PowerShell, whether via print, web, or presentation.
Posted by S.K. _ on 5/10/2013 at 4:51 PM
How The following script should work?
Operator names should be reserved?

function foo ( [string]$split, [string[]]$join )
if ($split) { $split -split '\' }
if ($join) { Remove-Item $join }

$split = "foo bar fiz buzz"
$join = Get-ChildItem * | % fullname

foo -split $str
    -Join $files
Posted by PowerShellDon on 5/10/2013 at 1:13 PM
Agreed. Relying on the escape character is problematic because (a) in many mediums it is difficult to see, looking like stray toner or a dead pixel, and (b) if it isn't immediately followed by the CRLF then it doesn't work. Implementing some kind of scan-ahead in the parser - hey, here's a CRLF, let's see if there's a pipe on the next line - would remove much of the need to use the backtick in this way. Alternately, create a dedicated, does-nothing-else line continuation character a la VBScript's _.
Sign in to post a workaround.
Posted by qa_warrior on 5/14/2013 at 7:39 AM
most of these formatting issues when using named Parameters and and Arguments by using Splatting.

$GCIParam = @{
Get-ChildItem @GCIParam |
Select-Object -Property FullName