Powershell: 우리는 사용할 수 | 다음 줄에 연속 문자로?

스크립트에서 - 예, 하지만 입력 후 완전한 명령줄을 갖게 되기 때문에 콘솔에서 기존 방식의 마우스 오른쪽 버튼 클릭 또는 Alt+e,p 붙여넣기를 사용하는 기능이 중단됩니다.

관련 토론 #2819

대화식 세션에 대한 잘못된 UX가 표시됩니다. 첫 번째 NewLine 파서는 다음 NewLine 을 기다리거나 최대 | 또는 NewLine 까지 공백을 건너뜁니다. 이는 사용자를 혼란스럽게 합니다. .

스크립트의 경우 다음과 같이 항상 입력할 수 있으므로 연속 문자 `(백틱)를 제때에 삭제하라는 요청입니다.

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

파서는 이미 다른 곳에서 이 작업을 수행합니다.

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

@lzybkr 분명히 그런 식으로 여러 줄을 쓰기 _ 반드시 _하지 평균 명 않는 이해 할 수있을 파서를 가진 - 많은 사람들이, 심지어 "자신의 라인에 중괄호"다른 스타일의 일이 위와 같이 스트로브 스트 룹 스타일을 채택 브레이크 붙여 넣기 (특히 PSReadLine이 오른쪽 클릭을 엉망으로 만들고 Ctrl+V가 작동하도록 했기 때문에). 차이가 없어야 합니다.

@iSazonov 대화식으로 Enter 키를 누르면 기다리지 않고 실행됩니다. 위의 else 지금처럼. shift + enter 를 눌러 콘솔에 입력할 수 있습니다(PSReadLine이 있는 경우).

PSReadline은 오른쪽 클릭으로 엉망이 되지 않습니다. TAB 문자가 PSReadline이 없는 것으로 확장되는 경우가 있지만 이는 여러 줄 입력이 다음과 같이 작동하지 않는 방식과 더 관련이 있습니다. PSReadline을 사용하지 않는 경우 예상됩니다.

그러나 내 요점은 정말 간단했습니다. 대화형 경험은 가능한 한 스크립트에 동일한 텍스트를 넣는 것과 최대한 유사하고 이상적으로 동일하도록 의도되었습니다. 이 기능은 일반적으로 사용되는 시나리오(오른쪽 클릭)에서 의도와 다릅니다.

이 시점에서 저는 이 제안에 대해 어떤 식으로든 판단을 내리는 것입니다. 모든 사람에게 분명하지 않을 수도 있는 무언가를 지적하는 것입니다.

오른쪽 클릭-붙여넣기는 각 줄을 shift+입력한 다음 실행하는 것처럼 전체 클립보드 버퍼를 콘솔에 붙여넣는 일부 현대화를 사용할 수 있습니다. 이 문제를 고려하지 않더라도 그 자체로 유용할 것이라고 생각합니다. 정확하지 않은 것을 마우스 오른쪽 버튼으로 클릭하여 붙여넣고(분석 오류) 몇 가지 명령이 산재되어 있는 많은 오류 메시지를 본 적이 몇 번이나 될까요? 그 실행? 그것은 당신이 것을, 죄송합니다 (붙여 넣기 한 내용에 따라 매우 해로울 수 cd 내 현재 C에 머물도록 명령을 제대로 분석하지 않았다는 \ 디렉토리 del *.* -r -fo 명령이 실행. ..). 오른쪽 클릭-붙여넣기가 실제로 전체 블록을 붙여넣고 PowerShell이 ​​실행 측에서 이미 잘 처리한다면 더 좋을 것입니다.

기술적으로 오늘날의 대화형 환경은 마우스 오른쪽 버튼 클릭-붙여넣기가 명령 모음이 아니라 붙여넣을 때 명령을 실행하기 때문에 스크립트에 동일한 텍스트를 넣는 것과 이미 다릅니다. 결과는 구문 분석 오류가 스크립트에서 수행하는 동안 오른쪽 클릭-붙여넣기에서 부분 실행을 방해하지 않는다는 것입니다.

또한 대화형 ad-hoc PowerShell의 경우 사용자가 콘솔에 여러 줄 명령을 입력하여 입력하는 것은 매우 드문 일이며 오늘날 이 작업을 수행하는 사용자의 경우 항상 하던 대로 계속할 수 있습니다. 완료. 우리의 나머지 일반 사람들을 위해 우리의 파이프라인은 우리가 마우스 오른쪽 버튼을 클릭하여 붙여넣기를 하지 않는 한 한 줄에 있을 것입니다. 위에서 지적했듯이 대화형 경험이 실제로 가능한 한 가깝도록 개선될 수 있고 아마도 개선되어야 할 것입니다. , 이상적으로는 동일한 텍스트를 스크립트에 넣는 것과 동일합니다.

요약하자면: PowerShell이 ​​줄 시작 부분에 줄 연속 문자가 없는 파이프라인을 지원하도록 하고, 대화형 사용과 스크립팅 경험 간에 더 나은 일관성이 있도록 마우스 오른쪽 버튼 클릭-붙여넣기를 수정하라는 요청에 대해 +1입니다.

오른쪽 클릭은 PowerShell 기능이 아니라 conhost 기능입니다. Conhost는 타이핑 시뮬레이션이 현재 콘솔 프로세스와의 일부 조정 없이 붙여넣기와 동일하다고 항상 가정할 수 없습니다.

예. 오른쪽 클릭 붙여넣기가 어색할 수 있습니다. else 와 똑같은 방식으로.

이렇게 하면 여러 파이프가 있는 명령(콘솔과 파일 모두에서)을 훨씬 더 읽기 쉽게 만들 수 있으며 이전에 지적한 대로 if/else가 프롬프트에서 실행될 때와 똑같은 문제가 발생합니다.

지금까지 | 줄의 마지막 문자가 연속 문자로 작동했기 때문입니다. 이 변경은 특히 이전 동작이 작동하지 않는 경우 무엇을 가져옵니까?

내 iPad에서 보낸

2017년 3월 8일 17:04에 Michael T Lombardi < [email protected] [email protected] >이(가) 다음과 같이 썼습니다.

이렇게 하면 여러 파이프가 있는 명령(콘솔과 파일 모두에서)을 훨씬 더 읽기 쉽게 만들 수 있으며 이전에 지적한 대로 if/else가 프롬프트에서 실행될 때와 똑같은 문제가 발생합니다.

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub https://github.com/PowerShell/PowerShell/issues/3020#issuecomment-285101638 에서 확인하거나 https://github.com/notifications/unsubscribe-auth/AHgYUW- 스레드를 음소거합니다.

이 변경으로 인해 | 가 EOL _뿐만 아니라_ 새 줄의 시작 부분에서 계속 문자가 될 수 없도록 해야 합니까? 나는 그것을 기대하지 않을 것입니다.

@RichardSiddaway 그것은 가독성에 관한 것입니다. 이것은 사례 및 스타일 저장소의 줄 바꿈에 대한 토론에서 여러 번 나타났습니다. 어떤 사람들은 줄 끝에서 백틱을 사용하여 이미 이런 식으로 쓰고 있습니다.

줄의 첫 번째 항목으로 파이프 문자를 사용하면 특히 줄이 길고 끝에서 파이프를 쉽게 볼 수 없는 경우에 연속이라는 것을 _정말_ 분명하게 알 수 있습니다.

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

대

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

들여 쓰기 위의 예에서 @jaykul 은 시력 관점에서 유용합니다. 파이프 기호는 추가(IMO 불필요) 표시일 뿐입니다.
당신의 예를 고려할 때, 이것이 당신에게 그렇게 호소력이 있습니까?

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

내 눈에는 다음과 같이 매우 이해할 수 있습니다.

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

도움이되는 것은 들여 쓰기입니다 (그리고 이것이 내가 일반적으로 쓰는 방법입니다)

FWIW, 나는 긴 파이프라인에서 백틱의 사용을 이해하지 못했고 필요하지 않았기 때문에 코드 리뷰에서 백틱을 볼 때마다 스쿼시를 시도했습니다.

첫 번째 예에서와 같이 파이프를 첫 번째 문자로 명시적으로 선호합니다. @JamesWTruher (파이프와 명령의 첫 번째 문자 사이에 공백이 하나 있음에도 불구하고) - 계속되는 파이프라인에 대한 매우 명확하고 명확한 시각적 표시기를 제공합니다. . 들여쓰기는 코드를 스크롤할 때 유사하지만 덜 명시적인 추론을 제공합니다.

@Jaykul 이것은 대화식 명령줄 경험을 완전히 깨뜨릴 것입니다. 예를 들어 명령을 입력하고 return 키를 누릅니다.

PS> dir
>

출력이 나오나요? 아니오, 파서가 연속이 될 _수도 있는_ 다음 토큰을 기다리고 있기 때문에 그렇지 않습니다. 이제 리턴 키를 두드리십시오. 파서가 토큰이 연속인지 확인하기 위해 여전히 기다리고 있기 때문에 더 많은 프롬프트가 표시되는 것을 제외하고는 아무 일도 일어나지 않습니다.

PS> dir
>
>

확인 - | sort Length 하고 리턴을 누르십시오.

PS> dir
>
>
> | sort Length
>

그리고 여전히 _still_이 연속 토큰일 수 있기 때문에 아무 일도 일어나지 않으므로 여전히 새 라인을 수신해야 합니다. 이제 당신은 '나는 이것으로 끝났습니다 - 그것은 작동하지 않습니다. 날짜를 잡자'라고 말합니다. Get-Date 하고 return 키를 누릅니다. 예 - 출력을 얻습니다. 하지만 Get-Date 부터가 아닙니다. 아니요 - 마침내 dir | sort Length 명령을 완료했으므로 이것이 표시되는 출력입니다. 그동안 명령 판독기는 이제 Get-Date 시작한 명령을 완료하기를 기다리고 있습니다. 아니면 모든 것이 단지 오류일 수 있습니다.

이것은 모든 사용자에게 끔찍한 대화형 경험이 될 것입니다.

파일에서만 작동하도록 만들 수 있습니까? 예 - 아마도 @lzybkr이 언급했듯이 우리의 기본 설계 원칙 중 하나는 명령줄에서 작동하는 것이 단순히 파일에 붙여넣고 그 반대의 경우도 마찬가지라는 것이었습니다. emdash 및 endash 문자가 있는 Word 문서에서 붙여넣기도 지원합니다.

그래서 실제로 '|' Haskell 패턴 일치와 같은 것에서 줄의 시작 부분을 봅니다.
fib n | n == 0 = 1 | n == 1 = 1 | n >= 2 = fib (n-1) + fib (n-2)
PowerShell에서는 작동하지 않습니다.

내부에 관해서는 내가 갓 태어난 아기라는 경고와 함께 다음과 같은 몇 가지 관찰 사항이 있습니다.

# This works everywhere
Get-Process |
Select-Object -First 1

# This errors at the prompt unless using soft returns, note the two blank lines;
# hitting enter after the first one causes it to error out.
# Note that with soft returns you can go just about forever before adding the next line.
Get-Process |


Select-Object -First 1

# This will run fine in either
If ($false) {
  ' False Output'
} Else {
  'True Output'
}
# This will error in the prompt (unless using soft returns) but pass in a file
If ($false) { 'False Output' }
Else { 'True Output' }

제쳐두고, 나는 껴안지 않은 if/else가 하는 것처럼 소프트 리턴 없이 프롬프트에서 다음이 실패할 것으로 예상/괜찮습니다.

Get-Process
| Select-Object -First 1

나는 프롬프트에서 대화형일 때 가독성, 특히 한눈에 보는 가독성에 대해 특별히 신경 쓰지 않지만(일반적으로 나는 잠시 전에 썼기 때문에) 스크립트와 모듈을 작성/유지할 때 주요 관심사 중 하나입니다. 다른 사람의 작업 디버깅 등

@JamesWTruher 를 다루기

Get-Process | Where CPU | Where Path
| Get-Item | Where FullName -match "AppData"
| Sort-Object FullName -Unique # I'm so proud of this highlighting "bug" by the way

@BrucePay 맞아요. 대화형 경험은 _명시적으로_ 지원하지 않습니다.

정말 대화형과 스크립트 간에 차이가 없다고 생각한다면 _가끔 PSReadLine 없이 PowerShell을 사용해 보아야 합니다_.

ISE 또는 VS Code에서 콘솔을 사용해 보십시오.

"missing statement block" 또는 "empty pipe element" 유형 예외를 처리할 PSReadline이 없으면 파이프 뒤에 줄 바꿈

Get-Process |
Where CPU

if($True)
{



md5-9d813a39f05f47b572d1068b0164b382



Or whether I will write the (necessary) generic `catch { "You threw $_" }` handler after



md5-6b461006504b741b884d4fb3f126b489



And it won't let me put a comment where it thinks there should be code, so neither of these is possible:



md5-adc435ab733361316365acfc69de09df



```posh
Get-Process |
# I only want actual apps, with windows
Where MainWindowHandle

예, 이것은 스크립트에서 줄 바꿈을 사용할 수 있지만 콘솔에서는 사용할 수 없는 _또 다른 장소_입니다. 하지만 이미 많은 것들이 있습니다(_특히_ PSReadLine을 사용하지 않는 경우).

@Jaykul 1 및 @JamesWTruher 2 의 코드를 참조하려면 다음을 사용합니다.

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

지적했듯이 들여쓰기로 인해 코드를 빠르게 스캔할 때 읽기가 훨씬 쉬워집니다. 파이프를 보기 위해 끝 부분을 볼 필요 없이 이 세 줄의 코드가 함께 '연결'되어 있다는 것을 알고 있습니다. 가독성은 코드를 작성할 때 가장 중요한 것 중 하나입니다.

나는 때때로 파이프 뒤에 백틱 문자를 추가하지만 _필요하지 않음을 기억할 때 나는 그것에 대해 나 자신을 표시합니다. 그것은 내가 깨려고하는 습관입니다 (브리칭이 아닌 백틱).

PSReadline을 사용하여 콘솔에 복사 및 붙여넣기해도 문제가 발생하지 않았으므로(기억할 수 있음) 토론 중간에 추가할 내용이 아닙니다.

파이프가 라인 끝이 아닌 다음 라인에 있게 하는 것은 매우 F#과 유사한 아이디어로 다음과 같은 작업을 수행할 수 있습니다.

F# let f1 str server = str |> parseUserName |> getUserByName server |> validateLogin <| DateTime.Now

그리고 저는 PS를 좀 더 기능적으로 만드는 모든 것에 찬성합니다(말장난 의도) ;)

F# 뿐만 아니라 Elm , Haskell , Elixir , 심지어 Google의 셸 스타일 가이드 (여기서 새 줄을 이스케이프 처리해야 한다는 점에 유의하세요...).

@michaeltlombardi Unix 셸과 마찬가지로 원하는 경우 PowerShell에서 줄 바꿈을 이스케이프 처리할 수 있습니다.

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

F#은 PowerShell과 달리 공백을 구분합니다(오프사이드 규칙). Elm, Haskell 및 Elixir는 물론 껍질이 아닙니다.

_나쁜 호스트에 대한 불만_...

인터프리터는 IncompleteParse 예외를 발생시켜 호스트 애플리케이션에 정보를 제공합니다. 이것을 포착하고 추가 입력을 요청하는 것은 호스트 구현에 달려 있습니다. 호스트가 잘못하면 호스트 소유자에게 항의하십시오.

대화형과 스크립트 간에 차이가 없다고 생각한다면 가끔씩 PSReadLine 없이 PowerShell을 사용해 볼 필요가 있습니다.

저는 PSReadLine 없이 10년 넘게 PowerShell을 사용했습니다. 그것으로 충분합니까?

소프트 리턴을 사용하지 않는 한 프롬프트에서 이 오류가 발생합니다. 두 개의 빈 줄에 유의하십시오.

처리 방법은 호스트 구현에 달려 있습니다. 이를 변경하려면 문제가 되는 호스트에서 문제를 엽니다.

if/else가 프롬프트에서 실행될 때와 똑같은 문제입니다.

예. 모호합니다. 죄송합니다. 안정적으로 작동하게 할 방법이 생각나지 않았습니다. C#의 중괄호 스타일을 일치시키는 대신 OTBS를 사용했다면 이것은 중요하지 않았을 것입니다. 사실 OTBS(예: DSL)를 사용하면 많은 이점이 있습니다. 또한 참고: 원래 콘솔 호스트에서는 첫 번째 IncompleteParse 예외를 수신한 후 호스트가 빈 줄에 도달할 때까지 계속 줄을 읽고 결과를 실행했기 때문에 "작동"했습니다. 그러나 이것은 항상 여분의 줄 바꿈을 눌러야 함을 의미합니다.

@Jaykul 그럼 F#의 #light 지시어의 반대를 원하십니까? 공백이 관련이 없고 세미콜론이 필수인 #heavy와 같은 것입니까?

내 생각에 PS에서 줄 바꿈을 이스케이프하는 것은 대부분의 언어보다 문제가 더 많습니다. PS의 이스케이프 문자는 빌어먹을 백틱 입니다. 구문 강조 표시는 실제로 대부분의 경우 눈에 띄게 만들지 않습니다. 대부분의 강조 표시 구성표는 색상을 상당히 둔하게 만듭니다.

거기에 다시 돌아가서 백틱이 흩어져 있는 것을 편집할 때 실수로 백틱을 놓칠 확률이 상당히 높습니다.

백틱 실수를 추적하는 것이 건초 더미에서 바늘을 찾는 것과 같지 않은 경우 이 형식을 사용합니다. 아니요, 줄을 이스케이프하지 않고 파이프에서 시작 형식을 자체 스타일로 허용하는 것이 더 낫다고 생각합니다. :/

@vexx32 '`'이(가) 보기 어렵다는 데 동의하지만 '|' 아니다.

@Jaykul 그럼 F#의 #light 지시어의 반대를 원하십니까? 공백이 관련이 없고 세미콜론이 필수인 #heavy와 같은 것입니까?

@BrucePay가 아니라 다음과 같은 또 다른 구문 트릭이 필요합니다.

try { throw 5 }
catch [ArgumentException] {  <# ... #> }
catch { Write-Warning Whatever }

콘솔에 입력할 때 작동하는지 여부에 대해 걱정하지 않고 스크립트로 _깔끔하게_ 작성하겠습니다.

@BrucePay 맞습니다. 저는 이러한 백틱을 사용하는 일부 코드를 가지고 있지만 여기서 우리가 찾고 있는 것은 @vexx32가 나열된 모든 이유 때문에

사람들이 실제로 의존하는 PowerShell의 여러 기존 동작은 실제로 호스트 구현의 결과라는 점을 지적하는 것은 완전히 공정합니다. 따라서 이러한 사항을 명확히 해주셔서 감사합니다! 다른 한편, 이것은 호스트 구현이 이를 처리하기 위해 추가 작업을 수행하지 않는 한 이미 이러한 기대를 깨뜨리는 언어의 요소가 있음을 의미합니다. 그렇죠?

@michaeltlombardi 잘못된 호스트 구현은 대화형 환경을 열악하게 만들지만 언어 자체에는 영향을 주지 않습니다. 즉, 대부분의 PowerShell '스크립트'가 대화형으로 입력되기 때문에 대화형 환경은 매우 중요합니다.

우리가 여기서 찾고 있는 것은 그것들 없이 코드를 작성할 수 있는 능력입니다

요점은 | 를 줄 끝에 넣으면 연속이 암시적이며 요청에 따라 연속 문자가 필요하지 않다는 것입니다. 그리고 | 기호는 보기 쉽습니다. 그리고 들여쓰기를 사용하여 코드의 구조를 명확하게 볼 수 있도록 합니다. F# 또는 Python과 달리 PowerShell은 셸이고 때로는 매우 조밀한 코드를 작성해야 하기 때문에 들여쓰기를 적용하지 않습니다.

@Jaykul

콘솔에 입력할 때 작동하는지 여부에 대해 걱정할 필요가 없습니다.

콘솔 경험은 우리와 대부분의 고객에게 여전히 주요 시나리오입니다. 그러나 실험적 기능을 지원하기 위한 메타 기능이 준비되어 있습니다. 우리는 당신이 원하는 것을 시도할 수 있고, 실험적 기능으로 노출된 다음, 전반적인 경험에 대해 어떤 종류의 피드백을 받는지 확인할 수 있습니다.

콘솔 경험이 기본이라는 것을 완전히 이해합니다. 내 요점은 _first_ 의견에서 제안한 것처럼 콘솔이 손상 되지 않아야 한다는 것 입니다.

콘솔에서 작동해야 _같은 방식으로_ 두 번째 catch 가 위에서 수행합니다. PSReadLine과 같은 여러 줄 ReadLine이 있는 콘솔에서만 입력할 수 있고 Shift+Enter 를 삽입할 수 있습니다. 추가 줄(또는 붙여넣을 수 있음) -- 기존 동작을 전혀 변경할 필요가 없습니다.

결국 이것은 타이핑을 줄이는 것이 아니라 코드 서식을 개선하기 위한 기능입니다. 대화형 콘솔이 아닌 스크립팅 환경에서 작동해야 합니다.

그러나 처음부터 사용자에게 한 약속 중 하나는 스크립트(예제 등)에서 콘솔에 붙여넣고 작동하게 할 수 있다는 것이었습니다. 여기에는 emdash 등의 단어 문서에서 붙여넣기가 포함되었습니다. 복사 및 붙여넣기는 단연코 가장 일반적인 재사용 형식입니다(이를 검증하기 위한 연구를 수행했습니다)

오른쪽. 그러나 복사-붙여넣기는 현재 PSReadLine의 Ctrl+V에 붙여넣는 동안에만 _완전히_ 참이며 오른쪽 클릭을 통하지 않고 이 변경 사항 도 작동 합니다. 즉, 여러 줄 붙여넣기가 가능한 ReadLine이 필요하지만 기본적으로 PowerShell 5+에서 작동합니다.

위에서 언급했듯이 PSReadLine이 _없는_ 경우가 아닌 _이미_ 있는 경우(if/else, try/catch, 주석, Allman 중괄호 등)가 꽤 있습니다.

내 생각에는 PSReadLine이 아닌 호스트의 문제 목록에 대한 또 다른 극단적인 경우는 기능을 제외할 만큼 충분히 큰 이유가 아니라는 것입니다. 결국 이 구문은 PowerShell 4 또는 5에서 작동하지 않으므로 ISE 또는 PSReadline이 아닌 호스트에서는 작동하지 않습니다. 우리가 {{not-our-problem}}에 붙여넣는 _더_많은_ 문제에 대해 토론하는 데 이렇게 많은 노력을 기울이고 있다는 것이 _저를 조금 미치게 만듭니다_ 하지만 이전 버전에서는 작동하지 않는 구문이라는 사실에 대해서는 괜찮습니다. PowerShell 버전...

추신: 저는 BestPractices 가 Stroustrup 또는 Allman보다 OTBS를 선택 하는 정당화 중 하나로 붙여넣기 인수를 사용했지만 지금 책에서 이 스레드를 확실히 참조할 것입니다 😁

나는 우리가 장외 마권 발매소와 함께 사라 좋겠 정말 오래된. DSL은 훨씬 간단했을 것입니다.

OTBS는 물론 One True Way입니다....

@BrucePay- 여전히 여러 줄 명령줄을 붙여넣고 Ctrl+v를 사용하지 않는 사람들이 있다고 확신합니다. 하지만 그렇게 많은 사람들은 아닐 거라 생각하고 적응해야 합니다. 마우스 오른쪽 버튼 클릭이나 Alt+스페이스바 없이 붙여넣기

이 변화를 고려하는 것이 매우 합리적이라고 생각합니다.

누구든지 이 작업을 수행하기 위해 어떤 일이 일어나야 하는지에 대한 올바른 방향을 알려줄 수 있습니까? 최소한 작동하게 하고 어떤지 확인하고 싶습니다... 그런 다음 필요에 따라 약간 테스트할 수 있도록 실험 플래그 뒤에 추가할 수도 있습니다. 하지만 솔직히 말해서 다음과 같은지 잘 모르겠습니다. 그것은 정말로 필요합니다. 결국, 이것은 현재 경험에 대해 어떤 것도 변경하지 않을 것입니다. 단지 새로운 경험을 추가하기만 하면 됩니다.

줄의 시작 부분에 있는 그대로 파이프 요소가 현재 즉각적인 오류라는 점을 감안할 때 현재 이스케이프된 줄 바꿈을 사용하지 않고 따르고 있는 코딩 패턴이 아닙니다 . 이 변경 사항도 영향을 받지 않습니다. 그래서 정말... 여기서 잃을 것은 없고 모든 것을 얻을 수 있습니까?

작동하지 않을 수 있지만 시작해야 합니다.

diff --git a/src/System.Management.Automation/engine/parser/Parser.cs b/src/System.Management.Automation/engine/parser/Parser.cs
index a31f64fa0..37b897f7c 100644
--- a/src/System.Management.Automation/engine/parser/Parser.cs
+++ b/src/System.Management.Automation/engine/parser/Parser.cs
@@ -5653,6 +5653,11 @@ namespace System.Management.Automation.Language
                 }

                 pipeToken = PeekToken();
+                if (pipeToken.Kind == TokenKind.Newline)
+                {
+                    SkipNewlines();
+                    pipeToken = PeekToken();
+                }

                 switch (pipeToken.Kind)
                 {

당신 말이 맞아요. 적어도 부분적으로는 현재 파서가 줄 바꿈의 수에 신경 쓰지 않기 때문입니다. 너무 많은 명령문 이 실행되지 않습니다 . 진행 방법에 대해 몇 가지 잠재적인 생각이 있습니다. 그래서 흥미로운 퍼즐을 주셨어요. 감사합니다! 💖

이와 같은 스레드는 PowerShell 오픈 소싱이 우리에게 가져다준 엄청난 이점을 실제로 보여줍니다. 우리 모두가 제품 팀, MVP, 신뢰할 수 있는 커뮤니티 구성원 및 이와 같은 언어를 처음 접하는 사람들과 훌륭하고 공개적으로 토론할 수 있는 것은 다음과 같습니다. 환상적이다. 이 스레드의 앞부분에서 @Jaykul 의 응답을 인용

위에서 @Jaykul이 말한 것의 핵심 부분은 명령의 연속이 줄의 끝이 아닌 줄의 시작 부분에 있다는 것을 이해하고 읽는 것이 더 쉽다는 것입니다.

@RichardSiddaway 그것은 가독성에 관한 것입니다. 이것은 사례 및 스타일 저장소의 줄 바꿈에 대한 토론에서 여러 번 나타났습니다. 어떤 사람들은 줄 끝에서 백틱을 사용하여 이미 이런 식으로 쓰고 있습니다.

줄의 첫 번째 항목으로 파이프 문자를 사용하면 특히 줄이 길고 끝에서 파이프를 쉽게 볼 수 없는 경우에 연속이라는 것을 _정말_ 분명하게 알 수 있습니다.

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

대

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

네, 앞으로도 하고 싶습니다.

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

조만간 또 한번 시도해봐야겠네요. 흥미로운 퍼즐이지만 아직 해결 방법을 잘 알지 못합니다. 😕

나는 이것이 훌륭하다는 점 에서

나는 또한 줄 시작 부분에 줄 연속 문자를 사용하는 _옵션_을 가질 수 있는 것이 좋을 것이라는 @RichardSiddaway의 의견에 동의합니다. 저는 가독성을 위한 코딩을 적극 옹호하므로 들여쓰기(즉, 첫 번째 옵션)를 사용하고 만족합니다. 저는 실제로 두 번째 옵션의 모양이 마음에 들지 않지만(저는 보기에 보기 흉하다고 생각합니다. :)) 모호함을 없애줍니다. 그리고 가독성이 향상된다면 선택의 여지가 있는 사람들을 위한 것입니다!

어젯밤 나는 파서를 만지고 싶은 기분이 들었고, 이것은 항상 나를 괴롭혔다( 나는 항상 라인의 시작 부분에서 파이프를 선호했다 ). 결과는 다음과 같습니다.

내가 가진 유일한 질문은 이것이 실험적 플래그 뒤에 숨겨져야 하는지 여부입니다. 테스트가 충분하다면 기존 기능에 영향을 미치지 않기 때문에 왜 전혀 실험적으로 만드나요? 생각?

이제 몇 가지 Pester 테스트로 마무리하기 위해 ...

동작이 예측 가능하고 일관되며 테스트 가능하다면 실험 플래그가 필요하지 않다고 생각합니다. 내가 말할 수있는 한 기존의 행동을 깨뜨리지 않습니다.

디자인에 대한 논란도 없는 것 같습니다.

또한 부수적으로 PowerShell에서 명령 이름이 "-"로 시작하도록 허용하는 것은 너무 나쁩니다. 그렇지 않으면 백틱 없이 개행에 매개변수를 래핑할 수도 있습니다. 물론 스플래팅이 있지만 명령 이름이 매개변수 이름과 일치하지 않으면 Intellisense 및 구문 강조 표시와 함께 작동할 수 있습니다.

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

나는 스플래터 같은 속편을 기다리고 있지만 확실히 첫 번째 캐릭터로 갖는 옵션이 훌륭하다고 생각합니다. 물론 대화형과 스크립트는 다르지만 PowerShell이 ​​이미 있는 방식과 일치합니다.

내가 가진 유일한 질문은 이것이 실험적 플래그 뒤에 숨겨져야 하는지 여부입니다. 테스트가 충분하다면 기존 기능에 영향을 미치지 않기 때문에 왜 전혀 실험적으로 만드나요? 생각?

지난번에 MSFT 팀이 왜 그렇게 수동적인지 모르겠지만 코드가 실험적 태그 아래에 있으면 빠르게 검토할 수 있습니다. 또한 powershell.config.json에서 기본적으로 기능을 활성화할 수 있습니다.

PowerShell에서 명령 이름이 "-"로 시작하도록 허용하는 것은 너무 나쁩니다.

전적으로 동의합니다. 이번 호에서 충분히 논의해볼 가치가 있다고 생각합니다. (삭제할 수 있는 다른 문자가 있습니다.)

"빈 파이프 요소는 허용되지 않습니다." 따라서 파이프가 줄 연속과 다음 줄 시작에 동시에 사용된 경우 호환성 문제가 없어야 합니다.

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

많은 불만 사항을 해결합니다. 백틱 없음, 연속성을 시각적으로 표시하기 위해 줄 시작 부분에 파이프; 연속 행이 예상되는지 여부를 알 수 있기 때문에 첫 행을 입력한 후 대화식 프롬프트 동작에 변경 사항이 없습니다. 예약된 || 연산자는 여러 줄로 나뉩니다. 백틱과 파이프를 사용하는 것보다 더 이상 타이핑이 아닙니다. Jaykul의 if/else , try/catch 예제에 따라 사이에 주석 줄에 문제가 있을 필요가 없습니다.

@HumanEquivalentUnit - 스크립트 작성자로서 cmdline 사용을 위해 스크립트 내에서 줄 바꿈을 제거하고 작동 불가능하고 직관적이지 않은 한 줄로 남을 수 있기 때문에 그 제안의 팬이라고 말할 수 없습니다. 그 IMO
가혹해 보인다

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

어느

@kilasuit 편집한 라인이 이상해 보이지만(저

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

제게 묻는다면, 솔직히 말해서 Kirk의 PR이 환영받는 분명한 이유일 뿐입니다. 백틱이나 추가 파이프가 필요하지 않아 라인을 응축할 때 매우 깔끔합니다.

초기 요청이 구현되었습니다.
이제 https://github.com/PowerShell/PowerShell-RFC/pull/179에 대해 논의합니다.