Can we use | on the next line as a continuation character?

I would like it if PowerShell could detect the pipe character as the first non-whitespace on a line as a continuation of the previous line, meaning we could write something like this:

$result = Get-Process
    | Where WS -gt 500mb
    | Format-Table VM, WS, CPU, ID, ProcessName

without having to add backticks!

In a script - yes, but that would break the ability to use the old school right-click or Alt+e,p paste in the console because after enter, you'd have a complete command line.

Related discussion #2819

I see bad UX for interactive session: after first NewLine parser will wait next NewLine or skip spaces up to | or NewLine - this will confuse the user.

For script this is a request to delete a continuation character ` (backtick) in time as we can always type:

$result = Get-Process |
     Where WS -gt 500mb |
     Format-Table VM, WS, CPU, ID, ProcessName

Jason Shirk (@lzybkr)

The parser already does this in other places.

if( 1 -eq (get-random 2)) {
    "True"
}
else {
    "False"
}

Jason Shirk (@lzybkr) obviously having the parser be able to do understand it doesn't mean people must write multiple lines that way -- many people have adopted stroustrup style as above, or even "brace on their own line" and other style things that break pasting (especially since PSReadLine messed with right-click and made Ctrl+V work). That shouldn't make any difference.

Ilya (@iSazonov) interactively, if you hit enter, it's not going to wait, it's just going to run it. Just like it does now with the else above. You can hit shift+enter to type it at the console (when you have PSReadLine).

PSReadline doesn't mess with right-click, although there is a corner case where a TAB character expands to something it wouldn't have w/o PSReadline - but that has more to do with how multi-line input isn't working as expected if you don't use PSReadline.

But my point was really simpler - the interactive experience was intended to be as close as possible, ideally identical, to putting the same text in a script. This feature would be a departure from that intent in a commonly used scenario - right click.

At this point, I'm saying making a judgement one way or the other on this suggestion, I'm just pointing out something that might not be obvious to everybody.

Right-click-paste could use some modernization, pasting the entire clipboard buffer into the console as if you had shift+entered each line and then running it that way. Even without considering this issue I think that would be useful by itself -- how many times have you right-click-pasted something that wasn't quite right (parse errors) and saw a bunch of error messages, perhaps interspersed with a few commands that executed? That could be quite harmful, depending on what you were pasting (oops, that cd command didn't parse properly, so I stayed in my current C:\ directory when the del *.* -r -fo command executed...). It would be better if right-click-paste actually pasted the entire block, and PowerShell handles that well on the execution side already.

Technically the interactive experience today is already different from putting the same text in a script because right-click-paste executes commands as they are pasted in, rather than as a collection of commands. The result is that parsing errors don't prevent partial execution in right-click-paste while they do in scripts.

Also, for interactive, ad-hoc PowerShell, I think it's pretty uncommon for users to enter multi-line commands by typing them in at the console, and for users who do this today, they can continue to do it just as they have always done. For the rest of us normal folk, our pipelines will be on a single line unless we right-click-paste, which as was pointed out above, could, and probably should, be improved so that the interactive experience really is as close as possible, ideally identical, to putting the same text in a script.

All to say: +1 for having PowerShell support pipelines at the beginning of a line without line continuance characters, and a request to fix right-click-paste so that there is better consistency between interactive use and the scripting experience.

Right click is not a PowerShell feature, it's a conhost feature. Conhost can't always assume simulating typing is equivalent to paste without some coordination with the current console process.

Yes. It might make right-click paste awkward. In exactly the same way else does.

This would make commands (both in the console and in files) with multiple pipes much more readable and, as pointed out before, has exactly the same issue that if/else does when executed in the prompt.

Up to now a | as the last character on a line has worked as a continuation character. What does this change bring especially if it stops previous behaviour working

…

Sent from my iPad On 8 Mar 2017, at 17:04, Michael T Lombardi <[email protected]<mailto:[email protected]>> wrote: This would make commands (both in the console and in files) with multiple pipes much more readable and, as pointed out before, has exactly the same issue that if/else does when executed in the prompt. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#3020 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AHgYUW-mDh_8nDUr671LdathDzLZPhS7ks5rjt9-gaJpZM4LohkD>.

Would this change necessarily require that a | couldn't still be a continuation character at EOL as well as at the beginning of a new line? I wouldn't expect it to.

RichardSiddaway

RichardSiddaway it's about readability -- this has come up several times in discussions about line-wrapping in the practices & style repo. Some people are writing this way already, just using backticks at the line ending.

Having a pipe character as the first thing on the line makes it really obvious that it's a continuation --much more so than just indenting it-- particularly if the lines are long and you can't easily see the pipe on the end.

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" | 
    Sort FullName -Unique

vs.

Get-Process | Where CPU | Where Path
    | Get-Item | Where FullName -match "AppData"
    | Sort FullName -Unique

Joel Bennett (@Jaykul)

Joel Bennett (@Jaykul) in your example above the indentation is just as useful from a visual acuity perspective. Pipe symbol seems to be just an additional (and IMO unneeded) indicator.
given your example, does this appeal as much to you?

Get-Process | Where CPU | Where Path
|Get-Item | Where FullName -match "AppData"
|Sort FullName -Unique

To my eye, this seems quite understandable:

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" |
    Sort FullName -Unique

it's the indentation that helps (and it's how I usually write this)

FWIW, I never understood the use of the backtick in long pipelines and tried to squash it whenever I saw it in code reviews, as it was unneeded.

James Truher (@JamesWTruher)

I do explicitly prefer the pipe as the first character, as in your first example, James Truher (@JamesWTruher) (albeit with a single space between the pipe and the first character of the command) - it gives a very clear and explicit visual indicator of a continuing pipeline. The indentation gives a similar, but less explicit, inference when scrolling over code.

Joel Bennett (@Jaykul)

Thread's like this really does show the immense benefits that open sourcing PowerShell has brought us and for us all to be able to a good and open discussion with the Product Team, MVP's, trusted community members and those that are new to the language like this is fantastic. Just to quote Joel Bennett (@Jaykul)'s response earlier on in this thread this would be the ideal end goal.

The key part of what Joel Bennett (@Jaykul) said above is that that we tend to find it easier to comprehend and read that continuation of a command is at the beginning of a line as to opposed to at the end of a line

RichardSiddaway it's about readability -- this has come up several times in discussions about line-wrapping in the practices & style repo. Some people are writing this way already, just using backticks at the line ending.

Having a pipe character as the first thing on the line makes it really obvious that it's a continuation --much more so than just indenting it-- particularly if the lines are long and you can't easily see the pipe on the end.
Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" | 
    Sort FullName -Unique
vs.
Get-Process | Where CPU | Where Path
    | Get-Item | Where FullName -match "AppData"
    | Sort FullName -Unique

So yes, I'd like to be able to do this in future

Get-Process | Where CPU | Where Path
    | Get-Item | Where FullName -match "AppData"
    | Sort FullName -Unique

I need to give this another attempt at some point soon. It's an intriguing puzzle, but not one I really know how to solve as yet. 😕

Ryan Yates (@kilasuit)

I agree with both Ryan Yates (@kilasuit) in that this is awesome we now have an open source version of PowerShell. As an aside I installed it on Manjaro Linux yesterday and wasa little in awe that it built it all from scratch. And so quickly.

I also agree with RichardSiddaway that it would be good to be able to have the option of using the line continuation character at the start of the line. I'm a big advocate in coding for readability so the indentation (ie. first option) is what I use and I'm happy with. I actually don't like the look of the second option (I think it looks ugly :)) but it takes any ambiguity out of it. And I'm all for people having choices if it improves readability!

Last night I felt like tinkering with the parser, and this always bugged me (I've always preferred pipes at the beginning of the line). Here is the result:

The only question I have is whether or not this needs to be hidden behind an experimental flag. If the tests are sufficient, why make it experimental at all, since it doesn't impact any existing functionality? Thoughts?

Now to wrap it up in some Pester tests...

I don't think it really needs an experimental flag, provided the behaviour is predictable, consistent, and testable. It's not breaking any pre-existing behaviour as far as I can tell.

It doesn't really seem like there's any contention over the design, either.

Also as a side note, it's too bad that PowerShell allows command names to start with "-". Otherwise we could probably wrap parameters on newlines without backticks as well. Sure we have splatting, but this could work with Intellisense and Syntax Highlighting if command names couldn't match parameter names:

Get-AzureRmAppServicePlanMetrics
    -ResourceGroupName Default-Web-WestUS
    -Name ContosoWebApp
    -StartTime 2016-11-30T22:00:00Z
    -EndTime 2016-11-30T22:30:00Z
    -Granularity PT1M
    -Metrics Requests

I am awaiting the splat-like sequel, but definitely think the option to have it as a first character is great. Sure it's different between interactive and script, but that is consistent with how PowerShell already is.

The only question I have is whether or not this needs to be hidden behind an experimental flag. If the tests are sufficient, why make it experimental at all, since it doesn't impact any existing functionality? Thoughts?

I don't know why MSFT team is so passive at last time but if you code will be under experimental tag I could fast review. Also we could enable the feature by default in powershell.config.json.

it's too bad that PowerShell allows command names to start with "-".

I'm full agree. I think it's worth it to discuss thoroughly in the new issue. (There are other characters we could put away.)

"An empty pipe element is not allowed", so there should be no breaking-compatibility problem if a pipe was used for line continuation and the start of the next line, at the same time:

Get-Process | Where CPU | Where Path |
    | Get-Item | Where FullName -match "AppData" |
    | Sort FullName -Unique

Which addresses many of the complaints - no backticks, pipe at the start of a line for visual indication of continuity; no change to the interactive prompt behaviour after typing the first line because it can tell whether to expect a continuing line; doesn't have much confusion with reserved || operator because it's split over multiple lines; is no more typing than using a backtick and a pipe; needn't have problems with a comment line in between as per Jaykul's if/else, try/catch examples.

HumanEquivalentUnit

HumanEquivalentUnit - I can't say that I am a fan of that suggestion because I as a script writer may decide that I want to remove the newlines within a script for cmdline use and would be left with an unworkable and non-intuitive single line that IMO
looks atrocious

Get-Process | Where CPU | Where Path |    | Get-Item | Where FullName -match "AppData" |    | Sort FullName -Unique

Which

Ryan Yates (@kilasuit)

Ryan Yates (@kilasuit) that edited line looks weird (doesn't look atrocious to me, just odd), but is that really any different from code with backticks which is valid now, if you removed lines without removing the line continuation? Do you currently suffer from that problem with backtick code?

Get-Process | Where CPU | Where Path `    | Get-Item | Where FullName -match "AppData" `    | Sort FullName -Unique

If you ask me, that's just a clear reason why Kirk's PR is welcome, to be honest. Not requiring either backticks or an additional pipe is very neat when condensing lines.

Initial request was implemented.
Now we discuss PowerShell/PowerShell-RFC#179

Navigation Menu

Repository navigation

Can we use | on the next line as a continuation character? #3020

21 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Can we use | on the next line as a continuation character? #3020

Description

Activity

lzybkr commented on Jan 19, 2017

iSazonov commented on Jan 20, 2017

Jaykul commented on Jan 20, 2017

lzybkr commented on Jan 20, 2017

KirkMunro commented on Jan 20, 2017

lzybkr commented on Jan 20, 2017

Jaykul commented on Jan 21, 2017

michaeltlombardi commented on Mar 8, 2017

RichardSiddaway commented on Mar 8, 2017

michaeltlombardi commented on Mar 8, 2017

Jaykul commented on May 13, 2017

JamesWTruher commented on Mar 15, 2018

michaeltlombardi commented on Mar 15, 2018

21 remaining items

kilasuit commented on Feb 10, 2019

vexx32 commented on Feb 10, 2019

pauby commented on Feb 11, 2019

KirkMunro commented on Feb 19, 2019

vexx32 commented on Feb 19, 2019

KirkMunro commented on Feb 19, 2019

dustindortch commented on Feb 19, 2019

iSazonov commented on Feb 19, 2019

HumanEquivalentUnit commented on Feb 21, 2019

kilasuit commented on Feb 21, 2019

HumanEquivalentUnit commented on Feb 21, 2019

vexx32 commented on Feb 21, 2019

iSazonov commented on Jul 12, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions