Powershell: null 조건부 멤버 액세스의 경우 변수 이름 주위에 { ... }가 필요하지 않습니다.

명확히 하자면, 이정표는 팀이 피드백을 기반으로 논의해야 하는 것이지 이 변경을 수행하기 위해 최선을 다한다는 의미가 아닙니다.

@mklement0

? {...}로 묶지 않고 식별자의 일부로 허용되어서는 안 됩니다.

음 - PowerShell의 초기 기본 언어는 $?를 사용하는 Posix Shell이었습니다. 종료 코드 qed '?' 따옴표 없이 변수 이름에 사용할 수 있습니다.

(의미있게) 이전 버전에서 실행할 수 없습니다.

물론 다음과 같이 할 수 있습니다.

PS>  $abc?=@{a=1; b=2; c=3}
PS>  $abc?.b                                                                                        1
PS>  2                      

물론 다음과 같이 할 수 있습니다.

새로운 의미로 의미 있게 실행할 수 없습니다(널 조건부 액세스) - 그게 제가 말하려는 전부입니다.

예, 귀하의 예제는 현재 작동하지만 _다른 의미로_ ( abc? _ ? _ 변수 이름으로 간주됨) - 그러나 명시된 이유로 인해 이 코너 케이스는 ?. 예상대로 작동합니다.

PowerShell의 초기 기본 언어는 종료 코드에 $? 를 사용하는 Posix Shell이었습니다.

$? 는 POSIX와 같은 쉘에서 _예외_입니다. 다음을 수행할 수 _없습니다_:

# bash, ksh, zsh, dash (all common /bin/sh implementations)
foo?='bar' # BOOM! E.g. "bash: foo?=bar: command not found"

(그리고 분명히 아무도 $? 가 PowerShell에서 폐지되도록 요구하지 않습니다.)

그리고 물론 $? (즉, $^ 및 $$ )와 같은 공간에 있는 _다른 모든_ 자동 변수는 명시적으로 특별하다는 점을 언급해야 합니다 $^ 토크나이저에 담았습니다. 그리고 사실 $? 도 마찬가지입니다. 비록 (현재) 그럴 필요는 없습니다.

코드가 작성될 당시 ? 가 유효한 식별자 문자가 아닐 것이라고 예상했던 것이 분명해 보입니다.

나는 스크립트에서 변수 이름 끝에 ? 를 사용한 사람을 한 명만 알고 있는데, 바로 @StartAutomating입니다. 그가 실제로 그 구문을 사용했기 때문에 이 토론에 그의 관심을 끌 만한 가치가 있다고 생각했습니다.

또한 @vexx32 , 토크나이저에서 $? 가 특별한 경우는 ? 시작하는 이름으로 변수를 생성할 수 없기 때문입니다. 예를 들어 $??? = 'foo' 는 구문 분석하지 않습니다. 변수 이름은 영숫자 또는 밑줄로 시작해야 하며 현재 영숫자, 밑줄 또는 물음표를 포함할 수 있습니다. ?. 가 null 조건부 멤버 액세스 연산자로 구문 분석되어야 한다는 데 동의하지만 ? 가 토크나이저에서 특수한 경우인 이유를 명확히 하고 싶었습니다.

이 채팅에 관심을 가져주셔서 감사합니다.

가치 있는 일에 대해 다음과 같은 몇 가지 생각이 있습니다.

1. 이러한 변수는 드물지만, back-compat이 스크립트를 중단할 때 아무도 두더지 잡기를 원하지 않습니다.
2. 아주 괴짜스러운 사람들은 제쳐두고 ${obj}?.Method() 또는 $obj?.Method()가 약간 증가할 것으로 예상합니다. 웹에서 null을 관리하는 방법에 대한 10년 간의 지침이 있으며 많은 사람들이 if ($obj) { $obj.Method() } _v7 대세를 타기 위해 전환하는 것을 보지 못했습니다.
3. 또한 예상치 못한 변수 이름에 문제가 있는 대부분의 사람들은 ${} 구문을 배웁니다(이미 밑줄로 자연스럽게 적중했을 것입니다). "이 기능을 사용하려는 사람"과 "${} 구문을 이미 알고 있는 사람"의 벤 다이어그램 겹침이 거의 100%일 것으로 예상합니다.
4. 이 구문은 전체 하위 표현식만큼 강력하지 않고 전체 하위 표현식은 코어에서 작동하거나 작동하지 않기 때문에 대부분의 사람들이 앞으로도 계속 사용할 것으로 예상합니다.

따라서 수학을 실행하면 이 작업을 수행하지 _하지 말아야 하는 몇 가지 구체적인 이유와 이를 수행해야 하는 모호한 이유가 있습니다(일부 사용자에게는 더 쉬울 수 있음). 의 낮은 유병률을 감안할 때? 변수 이름에서 당신은 당신이 해하는 것보다 더 많은 사람들을 _어쩌면__ 도울 수 있지만 제 생각에는 그것은 동전 던지기입니다.

이러한 동전 던지기의 잠재적인 이점을 감안할 때 나는 Robert McNamara를 "만약 우리가 하면 망하고 그렇지 않으면 망할 것이고, 나는 우리가 하지 않으면 망할 것을 선택할 것입니다"라고 말하겠습니다.

$obj?.Method() 가 기본적으로 $<var i="6">obj</var> ?. <var i="9">Method</var>() 로 작동하고 $<var i="11">obj?</var> . 되돌아가도록 하는 것이 좋습니다. <var i="14">Method</var>() $obj 가 범위에 없지만 $obj? 는 있고 #requires ‑Version 는 v7+가 아닌 경우입니다.

@ExE-Boss, 이 특정 규칙에 대해 많은 예외가 있는 것 같습니다.

이 특정 규칙의 가치에 대해 다시 질문합니다.

그런 다음 질문은 "우리가 깨뜨릴 수 있는 변수 구문에 대해 우리가 모르는 것은 무엇입니까?"입니다.

합의가 이에 대한 ${...} 구문을 강제하는 것이라면 여기에서 OptionalFeatures에 대한 지원을 높이 평가할 것이므로 이 구문을 사용할 나 같은 사람들(저는 많이 사용할 것입니다)이 노이즈를 옵트아웃할 수 있습니다. .

여기서 의역하기 때문에:
"논리는 다수의 필요가 소수의 필요를 능가한다는 것을 분명히 나타냅니다." - 스팍

따라서 수학을 실행하면 이 작업을 수행하지 _하지 말아야 하는 몇 가지 구체적인 이유와 이를 수행해야 하는 모호한 이유가 있습니다(일부 사용자에게는 더 쉬울 수 있음).

@StartAutomating : 여러 가지 이유가 있으며 모호하지 않고 구체적입니다. 또한 이것의 목표 중 하나는 코드 단순성입니다. {} 변수 이름을 감싸야 하는 것은 해당 목표에 직접적으로 작용합니다.

저는 @mklement0 및 @KirkMunro 와 함께 합니다. 개인적으로 나는 ${...}? 구문이 부자연스럽고 불필요하다고 생각합니다. 우리는 이미 큰 변화를 겪었고 이 경우 명확성을 대가로 지불해야 하는 작은 대가입니다.

@StartAutomating

1. 또한, 예상치 못한 변수 이름에 문제가 있는 대부분의 사람들은 ${} 구문을 배웁니다( 이미 밑줄로 자연스럽게 적중했을 것입니다 ). "이 기능을 사용하려는 사람"과 "${} 구문을 이미 알고 있는 사람"의 벤 다이어그램 겹침이 거의 100%일 것으로 예상합니다.

이것은 유지되지 않습니다. 밑줄은 변수 이름의 유효한 문자입니다.

@vexx32

코드가 작성될 때 예상했던 것이 분명해 보입니다.

아니요.

문자를 바꾸시겠습니까? $foo.?Property 는 충돌하지 않는 것처럼 보입니다. 물음표로 시작하는 속성 이름에는 이미 인용 부호가 필요하기 때문입니다.

PS C:\> $foo = [pscustomobject]@{'?'=1; '?name'=2}
PS C:\> $foo.?name
At line:1 char:6
+ $foo.?name
+      ~
Missing property name after reference operator.
    + CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : MissingPropertyName
PS C:\> $foo.'?name'
2

@HumanEquivalentUnit , 불행히도 C# 및 기타 여러 언어에서 사용되는 오랫동안 확립된 ?. 구문과 영원히 혼동을 일으킬 수 있습니다(또한 인덱서( ${arr}?[0] 의 대체 형식을 찾아야 합니다 $arr[0]? 와 같은 것은 삼항 연산자와 혼동을 일으킬 것입니다)

깔끔한 해결책은 없습니다.

1. 알 수 없는 사람들이 사용? 변수 이름 끝에 선택적 기능이지만 "그 스크립트를 실행하는 경우 켜지 마십시오"라고 말할 수 있지만 이 기능을 켜는 사람은 소스가 무엇이든 현재 및 미래의 스크립트를 확인해야 합니다.
2. 대체 구문은 C#에서 그다지 강력하지 않은 것을 가져오기 때문에 좋은 옵션이 아닙니다.
3. #requires 기반 동작 변경은 저장된 스크립트 외부에서 작동하지 않으며 누군가 태그를 설정하지 않고 긴 스크립트에서 일부 코드를 복사하는 즉시 실패합니다.
   4. (dir *.ps2)?.count 및 (dir *.ps1)?.count 는 피연산자가 변수일 필요가 없음을 보여줍니다.
   ($Host)?.toString() / ($null)?.toString() 는 이름 주위에 중괄호를 넣을 필요가 없습니다. 여전히 추가 키 입력이지만 더 논리적이고 덜 보기 흉합니다.

1. #requires 기반 동작 변경은 저장된 스크립트 외부에서 작동하지 않으며 누군가 태그를 설정하지 않고 긴 스크립트에서 일부 코드를 복사하는 즉시 실패합니다.

이는 이전 버전에서 지원되지 않는 기능을 사용하는 _모든_ 코드에 적용됩니다.
이것이 최우선 문제라면 새로운 언어 기능이나 새로운 cmdlet/cmdlet 매개 변수가 도입되지 않았을 것입니다.

(희망은, 이전의 코드에서 당신은 적어도이 Set-StrictMode -Version 1 이 경우 효과, $var?.foo 에 의한라는 이름의 변수에 큰 소리로 실패를, var? 기존).

1. 이름 주위에 중괄호를 넣을 필요가 없습니다.

대체 (...) 위해 {...} 단지 한계 개선이다.

어떤 추가 구문이 사용되든 여기서 문제는 입력 편의성뿐만 아니라 _합리적인 기대_를 충족시키기 위해 _있는 그대로_ 작동해야 하는 추가 구문에 대한 _필요_입니다.

1. #requires 기반 동작 변경은 저장된 스크립트 외부에서 작동하지 않으며 누군가 태그를 설정하지 않고 긴 스크립트에서 일부 코드를 복사하는 즉시 실패합니다.

이는 이전 버전에서 지원되지 않는 기능을 사용하는 _모든_ 코드에 적용됩니다.
이것이 최우선 문제라면 새로운 언어 기능이나 새로운 cmdlet/cmdlet 매개 변수가 도입되지 않았을 것입니다.

그것은 내가 의미하는 것이 아니 었습니다. 더 나아가 #requires 지정된 pwsh 7인 경우 처리가 다를 수 있다는 제안이 있었습니다. #requires를 입력한 경우에만 새로운 동작을 활성화합니다.좋지 않다 .

(희망은, 이전의 코드에서 당신은 적어도이 Set-StrictMode -Version 1 이 경우 효과, $var?.foo 에 의한라는 이름의 변수에 큰 소리로 실패를, var? 기존).

내 경험상 Set-Strictmode를 많이 사용하지 않습니다. (a) 기본 설정이 "옳다"고 가정하고 (b) 해제에 의존하는 사용 빈도가 너무 높기 때문입니다. 이러한 연산자의 일반적인 용도입니다. 어쨌든 문제는 $var? 존재하고 foo 속성이 있지만 이제 코드는 $var를 찾습니다... $var가 존재하지 않기 때문에 strictmode가 설정된 경우 새로운 처리로 인해 오류가 발생할 수 있습니다....

1. 이름 주위에 중괄호를 넣을 필요가 없습니다.

대체 (...) 위해 {...} 단지 한계 개선이다.

예. ($x)는 ${x}보다 약간 낫지만 약간만 다릅니다. ( Get-user "Bob")?.disable() 가

$u = get-user "bob" 
($u)?.disable

어떤 추가 구문이 사용되든 여기서 문제는 입력 편의성뿐만 아니라 _합리적인 기대_를 충족시키기 위해 _있는 그대로_ 작동해야 하는 추가 구문에 대한 _필요_입니다.

예.
$var. foo 공백으로 작동합니다. ${foo} ?.bar() 하지 않기 때문에 ? 함수 또는 별칭 이름에서 허용됩니다(?.는 둘 다에 적합합니다). 일부 C# 구문을 기존 구문 규칙에 적용하는 것이 항상 실용적인 것은 아닙니다. 때때로 "C#에서 사용할 수 있습니다..."는 "네. 원하는 경우 C#이 어디에 있는지 알 수 있습니다."라고 대답할 가치가 있습니다.
:-)

SemVer 호환성을 유지하려면 주요 릴리스(바람직하게는 7.0.0 )에서 수행해야 합니다.

또한 위의 내 제안을 참조하십시오( https://github.com/PowerShell/PowerShell/issues/11379#issuecomment-566756120 ).

@ExE-Boss 네, 제가 #requires에 따라 처음에는 좋은 생각이 아닐 수도 있다고 말했을 때 언급한 귀하의 의견이었습니다.
그리고 예, 기존 스크립트를 중단하려면 주요 버전이 변경될 때이므로 신속하게 완료하거나 V8을 기다려야 합니다.

이것들은 아직 실험적인 기능이며 기본적으로 RC-1에서 꺼져 있습니다. 이 기능은 배송 제품에 대해 동일하게 유지될 것이라고 가정합니다. 또한 차단 / 특정 문자로 끝나는 변수를 만들려고 할 때 경고한다 - 즉 동작이 변경 (또는 두 번째 실험 기능이 될) 수 있도록 않습니다. 내가 그것을 활성화한 다음 나에게 책임을 지우는 잘못된 변수 이름을 가진 스크립트를 사용하려는 경우 - 물론 그것은 내가 다운로드한 스크립트가 "손상된" 것처럼 보이고 "실험적" 배너 아래에서 더 견딜 수 있음을 의미합니다.

저는 진지한 PowerShell 개발자가 아닙니다. 나는 버그에 대한 해결책을 찾기 위해 여기에 왔고 이 문제를 우연히 발견했습니다. 명령줄 스크립팅의 경우 주로 bash를 사용합니다. 저는 아마도 Microsoft가 PowerShell Core로 전환하도록 설득하려고 하는 인구 통계에 속할 것입니다. bash보다 고통이 덜한 빠른 스크립팅 언어가 필요한 크로스 플랫폼 개발자입니다.

주로 PowerShell 개발자가 아닌 사람들에게는 PowerShell 구문과 관련된 많은 결정이 직관적이지 않다는 것을 자주 발견했습니다. 마지막으로 심각한 작업에 PowerShell을 사용했을 때 null 병합 연산자가 없거나 대신 사용할 수 있는 삼항 연산자가 없다는 사실에 소름이 끼쳤습니다. 그 결과 이 인기 있는 PowerShell 답변을 Stack Overflow에 게시하게 되었습니다. 그게 2013년이었고, 그 이후로 내가 주로 PowerShell을 피한 세 가지 이유 중 하나입니다. 스크립팅 언어의 요점은 장황한 if-else 문이 아니라 많은 구문 설탕으로 빠르고 더러운 것을 원한다는 것입니다.

@StartAutomating 은 다음과

아주 괴짜스러운 사람들은 제쳐두고 ${obj}?.Method() 또는 $obj?.Method()가 약간 증가할 것으로 예상합니다. 웹에서 null을 관리하는 방법에 대한 10년 간의 지침이 있으며 많은 사람들이 v7 대세를 타기 위해 if ($obj) { $obj.Method() }에서 전환하는 것을 보지 못했습니다.

저는 n=1이지만 PowerShell이 ​​아닌 개발자로서 강력하게 동의하지 않습니다. 새로운? 구문은 몇 달에 한 번 PowerShell을 만지는 사람이라도 꽤 빨리 알아낼 수 있는 것입니다. 그러면 미래에 대안 대신 PowerShell을 사용할 가능성이 확실히 높아집니다. 그런 다음 이전 버전과의 호환성을 위해 일부 미친 {} 구문이 필요하다는 것을 알게 되면 눈을 감고 이미 사용하고 있던 항목으로 돌아갈 것입니다.

나는 여기서 이전 버전과의 호환성에 대한 강조를 이해하지 못합니다. PowerShell Core는 .NET Core에 없는 .NET의 일부를 사용했기 때문에 이미 대부분의 기존 스크립트를 중단했습니다. (나는 그것에 대해 불평하지 않습니다. .NET Core는 훌륭하지만 이전 버전과의 호환성을 중단하려는 경우 지금이 기회입니다.)

우선, 제 초기 피드백이 오해의 여지를 만들었다고 생각합니다.

내 가정은 ${}가 _PowerShell 개발자에게 그렇게 이상하지 않을 것이라고 생각했습니다. ? 또는 문자열에 밑줄을 긋습니다.

PowerShell이 ​​아닌 개발자에게는 이 구문이 어색할 수 있음을 알려주셔서 감사합니다.

내 피드백의 두 번째 부분은 혼합에서 길을 잃었을 수 있습니다. null 병합에 대한 다른 대안이 PowerShell에서 더 오랜 시간 동안 존재했고 널리 사용되기 때문에 이 기능이 _기존 PowerShell 사용자와 함께_ 얼마나 증가할지 모르겠습니다. 들어와서 "이것이 내가 PowerShell을 사용하기 시작하는 데 필요한 것 중 하나입니다"라고 말하고 싶고, 나는 당신의 의견에 이의를 제기할 수 없습니다. 정통).

내 피드백의 세 번째 비트는 비율에 맞지 않게 날아간 것 같습니다. $IsThisRight? = Test-Something , 이 변수 ​​제한에 대한 잠재적인 소식을 들은 첫 번째 반응은 "아 글쎄요. 일부 변수의 이름을 바꿔야 할 것 같습니다. 어쨌든 그렇게 많은 것을 얻지는 못했습니다."

따라서 스레드를 다시 작성하고 종료하려면 다음을 수행하십시오.

1. IMHO, ${}는 아마도 _existing_ PowerShell 개발자를 위한 구문이 그렇게 이상하지 않을 것입니다.
2. 이 기능이 훌륭하다고 생각할 수 있습니다. 나에게 그것은 언어 친숙도 관문 약물이며 이 스레드를 읽는 모든 사람이 if/foreaches/whiles 등을 할당하는 방법을 배우는 것이 좋습니다.
3. 영향을 받은 저자 중 한 명으로서 저는 ? 내 변수의 끝에서 내 코드를 변경하는 것에 반대합니다.

또는 간단히 말해서:

원하는 경우 이 변경을 수행합니다. 나는 이 경주에 작은 말이 있습니다. 이렇게 하기로 결정했다면 변경 사항을 명확하게 알려서 변수 이름을 지정한 다른 사람이 ? 따라 업데이트할 수 있습니다.

내 피드백의 두 번째 부분은 혼합에서 길을 잃었을 수 있습니다. null 병합에 대한 다른 대안은 PowerShell에서 더 오랜 시간 동안 존재했고 널리 사용되기 때문에 기존 PowerShell 사용자에게 이 기능이 얼마나 증가할지 모르겠습니다.

나는 확실히 그것에 동의하고 당신의 의견을 무시하고 싶지 않습니다. 특히 이미 언어를 많이 사용하는 사람들에게 대안이 직관적일 수 있는 경우에는 그러한 획기적인 변경을 수행하기가 항상 어렵습니다.

들어와서 "이것이 내가 PowerShell을 사용하기 시작하는 데 필요한 것 중 하나입니다"라고 말하고 싶고, 나는 당신의 의견에 이의를 제기할 수 없습니다. 정통).

글쎄, 나는 대부분의 비 PowerShell 개발자가 실제로 이러한 대화에 참여하지 않는다는 느낌을 받았습니다. 내가 우연히 이것을 발견한 것은 순수한 우연의 일치였습니다. 내가 PowerShell을 사용하는 것은 라이브러리와 오픈 소스 도구를 작성하는 사람들과 매우 다를 것입니다. 나는 PowerShell을 화려한 프레임워크로 사용하지 않고 가능한 한 빨리 이상한 작업을 완료하기 위해 더 많이 사용하는 사람의 관점을 제공할 것이라고 생각했습니다. 다른 의견을 무시하려는 것이 아닙니다. 여기에서 자주 볼 수 없는 관점에서의 또 다른 의견일 뿐입니다.

더 나은 null 처리는 내가 PowerShell을 더 많이 사용하기 시작하는 데 필요한 한 가지가 아니라 두 번째입니다. 첫 번째는 크로스 플랫폼 지원이었고, 나는 그것이 얼마나 멀리 왔는지에 매우 감동했습니다. 개인적으로 구문 설탕은 주어진 작업을 수행하기 위해 언어를 선택할 때 저에게 큰 문제입니다. 많은 사람들이 유지 관리해야 하는 것을 작성하는 경우 더 장황하게 작성하기를 원할 것입니다. 그러나 관리 또는 devops 작업을 위한 빠른 스크립트를 작성하는 경우 null과 같은 항목을 테스트하는 빠른 방법을 원합니다.

내 피드백의 세 번째 비트는 비율에 맞지 않게 날아간 것 같습니다. $IsThisRight? = Test-Something , 이 변수 ​​제한에 대한 잠재적인 소식을 들은 첫 번째 반응은 "아 글쎄요. 일부 변수의 이름을 바꿔야 할 것 같습니다. 어쨌든 그렇게 많은 것을 얻지는 못했습니다."

이전 버전과의 호환성을 선호하는 것은 항상 정당한 주장입니다. 그러나 이 특별한 경우에는 어쨌든 Core로의 전환으로 인해 많은 PowerShell 스크립트가 중단되기 직전인 것 같습니다. 이전 버전과의 호환성이 정기적으로 중단되면 답답하지만 모든 주요 변경 사항이 한 번에 발생하는 것을 선호하므로 지금이 좋은 시기일 수 있습니다.

완전히 새로운 인구 통계, 즉 Windows 중심이 아닌 개발자를 대상으로 하려는 시나리오에서는 이미 존재하는 것과 경쟁하기 위해 몇 가지 획기적인 변경이 필요할 수 있습니다.

이렇게 하기로 결정했다면 변경 사항을 명확하게 알려서 변수 이름을 지정한 다른 사람이 ? 따라 업데이트할 수 있습니다.

분명히 말씀드리자면 이 기능을 선택해야 하는 것은 괜찮습니다. 그렇다고 해서 PowerShell을 사용하는 데 방해가 되지는 않습니다. 나는 이미 내 bash 스크립트의 맨 위에 많은 set 명령을 필요로 하는 데 익숙합니다. 이상적이라고 생각하지는 않지만 문서화되어 있는 한 PowerShell 사용 결정에 거의 영향을 미치지 않습니다.

개인적으로, 구문 설탕은 주어진 작업을 수행하기 위해 언어를 선택할 때 저에게 큰 문제입니다.

그럼 당신은 올바른 언어에 왔습니다! PowerShell은 구문 설탕이 포함된 긍정적인 사카린입니다.

모르는 사람들을 교육하기 위해 PowerShell에서 여러 가지 방법으로 "null 병합"할 수 있습니다.
~$ListWhereNotNull = $null, 1, 2, $null, 3 -ne $null # 각 항목이 null이 아닌지 확인하고 1,2,3의 목록을 반환합니다.$FirstNonNull = @($null, 1, $null,2 -ne $null)[0] # 이것은 null이 아닌 첫 번째 값을 반환합니다.$lastNonNull = @($null, 1, 2, $null -ne $null)[-1] # 음수 인덱스를 사용하여 null이 아닌 마지막 값을 반환합니다.$TheObjectPipelineWay = $null, 1, $null, 2 | 개체 선택 - 처음 1$TheAssigningForeachWay = foreach($null의 $item, 1, 2, $null, 3, 4) {if ($item -ne $null) { $item;



지금은 그것으로 충분하지만 언어 구문이 훨씬 유연하다는 점을 증명해야 합니다. 이러한 모든 데모는 PowerShell 1.0까지 다시 작동합니다.

그러나 이 특별한 경우에는 어쨌든 Core로의 전환으로 인해 많은 PowerShell 스크립트가 중단되기 직전인 것 같습니다.

이것은 당신이 틀렸습니다. Core에는 실제로 구문을 깨는 변경 사항이 거의 없으며 코어에서 잘 작동한다고 생각하는 것보다 더 많은 모듈이 있습니다(+- Linux 대 Windows 경로 지정/줄 바꿈과 관련된 몇 가지 문제). 보다 실용적인 용어로, Windows 플랫폼별 API 종속성이 있는 경우 모듈이 Core에서 작동할 가능성이 적습니다(예: WPF 래퍼가 Linux에서 작동하도록 하기 위해 숨을 참지 않을 것입니다).

구문 변경으로 어느 쪽이든 여전히 괜찮습니다. 방금 최근 회신에 있는 두 가지 주장을 해결하고 호출해야 한다고 느꼈습니다.

Re: 문법적인 설탕, 내 냉소적인 마음은 영화 "스내치"를 인용합니다: "나는 이미 충분히 달콤합니다"
Re: Core의 변경 가능성 깨기: 지금은 거의 없고 가능한 한 그대로 유지합시다.

@StartAutomating : 내가 쏠 수 없다는 말입니까? 아직 설탕이 더 들어갈 곳이 있기 때문에 😜

모르는 사람들을 교육하기 위해 PowerShell에서 여러 가지 방법으로 "null 병합"할 수 있습니다.

나는 그것을 알아 냈지만 (그것은 내가 쓴 내 자신의 대답입니다), 그것은 덩어리처럼 느껴졌습니다. 많은 가능성을 가진 멋진 아이디어지만 스택 오버플로 답변에 대한 한 논평자가 지적했듯이 평가는 단락되지 않습니다. ?. 연산자는 호출/속성을 연결할 때 일반적으로 더 이상 문제가 되지 않음을 의미합니다. 하지만 2013년에는 사용할 수 없었습니다. 그리고 그때에도 이 예제에서 엄청나게 많은 일이 진행되고 있습니다. 댓글에서 사람들이 그것을 어떻게 혼란스럽게 여겼는지 알 수 있습니다. 이 예제가 기호별로 수행하는 작업을 정확히 분석해야 했습니다.

이것은 당신이 틀렸습니다. Core에는 실제로 구문을 깨는 변경 사항이 거의 없으며 코어에서 잘 작동한다고 생각하는 것보다 더 많은 모듈이 있습니다(+- Linux 대 Windows 경로 지정/줄 바꿈과 관련된 몇 가지 문제). 보다 실용적인 용어로, Windows 플랫폼별 API 종속성이 있는 경우 모듈이 Core에서 작동할 가능성이 적습니다(예: WPF 래퍼가 Linux에서 작동하도록 하기 위해 숨을 참지 않을 것입니다).

나는 실제로 적절한 통계를 수집하고 수집하기보다는 이와 관련하여 경험에서 말하는 것입니다. 예를 들어 pre-Core의 경우 [System.Web.Security.Membership]::GeneratePassword(32, 6) 사용하여 암호를 생성할 수 있지만 System.Web 는 Core에서 사용할 수 없습니다. (나는 아마도 이전 System.Web.dll을 로드할 수 있다는 것을 알고 있지만, 그럴 필요가 없다면 그렇게 하지 않을 것입니다.) 실제로 구문 변경은 누락된 API보다 해결하기가 더 쉽습니다. devkit에 대한 Docker 비밀을 생성하는 것은 빠른 스크립트를 사용하기에 좋은 장소처럼 보이지만 bash보다 PowerShell Core에서 놀랍게도 더 장황합니다. 물론 bash의 솔루션은 종종 보기 흉합니다.

Re: 문법적인 설탕, 내 냉소적인 마음은 영화 "스내치"를 인용합니다: "나는 이미 충분히 달콤합니다"

때에 따라 다르지. 때로는 PowerShell이 ​​매우 즐겁다고 느낍니다. null을 다루는 것은 내가 일반적으로 그렇게 느끼지 않는 핵심 영역 중 하나입니다. 비록 많은 언어에서 동일하게 말하겠지만요. 나는 또한 삼항 연산자나 bash의 && 및 || 연결에 비해 기존의 인라인 PowerShell if-else 문이 번거롭다는 것을 알았습니다. 이것은 몇 년 전 PowerShell에서 멀어지게 만든 주요 문제 중 하나이므로 언급할 가치가 있다고 생각했습니다.

반면에 저는 매일 다양한 언어를 다루며 무엇을 쓰든 항상 "X 언어로 하면 훨씬 쉬울 거에요!"라고 생각합니다. 저는 X 언어를 사용하고 있습니다. "Y 언어에서는 훨씬 쉬울 것입니다!"라고 생각합니다. 하지만 내가 큰 소리로 말할 기회가 있고 언어의 방향을 흔들 수 있는 기회가 있다면 나는 그것을 받아들일 것입니다.

저는 여기서 마음을 바꾸는 데 정말로 관심이 없습니다. 단지 다른 관점을 추가하는 것뿐입니다.

@StartAutomating : 내가 쏠 수 없다는 말입니까? 아직 설탕이 더 들어갈 곳이 있기 때문에 😜

나는 항상 새로운 구문 설탕을 사랑합니다! 나는 할로윈에 장난꾸러기 놀이를 하는 아이처럼 프로그래밍 언어를 선택합니다.

@Zenexer : 저는 Powershell을 정말 좋아합니다. 나는 직장에서 매일 PS를 광범위하게 할만큼 운이 좋습니다. 나는 유연성, 특히 .NET과의 공생을 좋아합니다. 이것이 내가 그 방향에 관심을 갖는 이유이며 ${...}? 구문이 저에게 너무 받아들이기 힘든 이유입니다.

좋은 지적이지만 몇 가지를 명확히 하겠습니다.

좋든 나쁘든 지금까지 PowerShell은 의미 체계 버전 관리를 사용하지 않았습니다.
새로운 주요 버전은 이전 버전과의 호환성에 대한 확고한 약속과 함께 _new_ 기능만 가져왔습니다.
주요 변경 사항이 Core에 서서히 들어오기 시작했는데, 부분적으로는 크로스 플랫폼으로 이동하기 때문입니다.
주 버전 v7.0은 이전 버전과의 호환성 _증가_를 나타내기 위해 선택되었습니다. 즉, Windows PowerShell에 대한 실행 가능한 대체를 제공하려는 시도입니다.

많은 역사적 문제는 기존 코드를 심각하게 깨뜨리지 않고 는 수정할 수 없으므로 선택적(옵트인) 기능으로만 제공될 수 있지만,
버킷 3의 주요 변경 사항은 항상 선택 사항이어야 합니다. 기존 코드를 중단할 _잠재적_이 있지만 실제로는 그렇지 않은 수정/개선을 수행합니다. 균형에서 언어를 개선할 가치가 있습니다.

OP에서 주장한 바와 같이 당면한 사례는 버킷 3 변경으로 저를 공격합니다. 우리는 _일부_ 스크립트가 깨질 것이라는 것을 알고 있지만 (

드문 이유는 무엇입니까?

변수 이름에 ? 를 사용하는 것은 대부분의 사람들에게 전혀 발생하지 않기 때문에, 만약 그렇다면 _without {...} _: 다음 모든 것이 다음과 함께만 작동한다면 {...} , 왜 ? 대해 다를 것으로 예상합니까?: . , ; ( : 는 항상 다음과 같이 해석되기 때문에 전혀 사용할 수 없습니다. 드라이브 분리기)

{...} 도 요구하지 않고 $var? 또는 $va?r 와 같은 이름을 허용하는 것은 문제를 요구하는 방임이었고 문제가 도착했습니다. 이 경우와 같이 언어.

C#에서 영감을 받은 3가지 새로운 관련 기능(적어도 구문 형식으로 관련됨)이 있습니다.

• 삼항 조건 - 7.0의 진정한 기능이 될 것입니다.
  
  
  
  • (Get-Date).Second % 2 ? 'odd' : 'even'
  
  
• Null-coalescing 연산자 - 7.0의 진정한 기능이 될 것입니다.
  
  
  
  • $var ?? 'default' 및 $var ??= 'default'
  
  
• Null 조건부 연산자 - 당면한 문제 - 7.0의 _실험_ 기능이 될 것입니다.
  
  
  
  • $possiblyNull?.ToString()
  
  

그들 모두는 구문의 일부로 ? 를 가지고 있으며, ?. 가장 분명하지만 다음과 같이 기존 $var? 구문 분석의 부담에 영향을 받습니다.

• $var?1:0 와 같은 것은 코딩 골퍼에게만 관심이 있다고 주장할 수 있지만 ? 에 구문 기능이 있으면 잘 작동합니다. 현재 ? 앞에 _space_를 사용해야 합니다

• 대조적으로, 누군가가 $var??='bar' (아마도 $baz = $foo??$bar 보다 적음)를 시도하는 것이 합리적이라고 생각합니다. 현재 또한 공백이 필요합니다.

즉, $var? 의 현재 구문 분석을 고수하면 _세 가지_ 새로운 기능(정도는 다양하지만)을 방해하게 되며, 그 중 2개는 이미 일반적으로 사용 가능합니다(실험용 아님).

{...} 를 요구하는 문제는 타이핑의 불편함이 _아닙니다_: 처음에는 _필요성을 기대하지 않고_ 나중에 _필요성을 잊는_(잠재적으로 미묘한 오작동과 함께) - 왜냐하면 너무 반 직관적입니다.

@ExE-Boss, 버전 조건부 동작을 구현하는 것이 문제가 될 수 있다는 @jhoneill의 의견에 동의합니다. 이 경우 하위 호환성 특수 케이스로 엔진을 방해할 필요가 없다고 생각합니다.

@ mklement0 : 그것은 자연스러운 / 직관 / 당신 이름 - 그것입니다. 대괄호는 단단하고 중괄호는 훨씬 더 어렵습니다. 이 경우에는 필요하지 않습니다.

@mklement0 이후 합의가

저는 아직 PowerShell에 C# 구문을 추가하여 완전히 설득하지 못했습니다. 키보드에 기호가 충분하지 않다는 문제가 이미 여러 곳에서 발생했습니다. ">" "보다 큼" 또는 "로 리디렉션"입니까? "=" 할당 또는 테스트 같음(다른 언어는 할당을 위해 :=를 사용하거나 같음을 위해 == 사용) 언어 사이를 이동하는 사람들은 -eq 또는 -gt 를 사용하는 것을 잊어버릴 것이고 우리는 그것에 집착합니다... Is + 산술 덧셈, 또는 문자열/배열 연결. *는 곱셈과 와일드 카드입니다. %는 모듈로이고 forEach-object. 의 별칭입니다.

가난한 ? Where-Object. 의 별칭이며 자동 변수의 이름입니다. 그러나 Get-Alias ? 또는 Get-Variable ? ... 를 시도하면 와일드 카드 작업을 수행합니다.

Get-PSdrive 를 수행하면 "변수" 등의 이름 끝에 ":"가 없고 이름에 하나를 추가하면 드라이브로 처리됩니다. 물론하지 않는 한 당신이 쓴 참조 "$drive="C" 하고 그것을 따라 "$drive:temp" '그들이 알고 당황한다 (그들은 그것에 대해 생각하지 않을과 오래된 손) PowerShell을 새로운 사람 방금 명명된 ​​범위 "드라이브"를 발명했습니다.

따라서 이에 대해 ... '":" 및 "?"를 추가로 사용하여 새 구문을 만들 수 있습니다. 제정신이에요?'
IIRC, 트위터 @Brucey 는 삼항 연산자를 "별로

대부분의 사람들은 $PSEdition.length -gt 2 쓸 것입니다.
하지만 $PSEdition. length-gt2 도 작동합니다(두 반쪽 사이에 줄 바꿈을 사용할 수도 있습니다.) "." "현재 디렉토리", "이 범위에서 실행" 및 "구성원" 역할도 하는 오버로드되지만 PS V1-V5에서는 선행 공백이 필요한 연산자를 생각할 수 없습니다. "." 하나가 _is_ 있으면 깨는 것이 이상합니다. 그러나 구문 분석을 위해 삼항 연산자 _might_는 선행 공백이 필요합니다.
$host.debuggerEnabled?0:1 는 "?"이기 때문에 OK입니다. 속성의 일부로 가정 _not_
$IsCoreCLR?0:1 는 "?" 때문이 아닙니다. 변수 이름의 일부로 간주됩니다.

null 병합 연산자도 마찬가지입니다.
$null?? "default" 에는 공백이 필요합니다. $true.length?? "default" 에는 공백이 필요하지 않습니다.

문제의 맨 위에 있던 원래 사용 사례를 잠시 한쪽으로 치워둡니다. 위의 경우는 무언가가 제대로 작동하지 않음을 보여줍니다. 변수 이름에 "?"가 포함된 경우 수정됩니다. "."가 포함된 이름처럼 중괄호가 필요합니다. 또는 "+" 또는 ":" 및 @StartAutomating 이 "?"의 주요 사용자입니다. in names는 처리할 수 있는 _break_라고 생각합니다. 널 멤버에 이르기도 전에 '이미 할 방법을 찾으십시오'처럼 들립니다.

내가 필요로하는 실험적인 기능에 넣어 짧은 시간 창이 있다고 생각? 이름을 중괄호로 묶고 해당 기능이 켜져 있는 경우 - 이것이 기본값이어야 합니다 - 모두 새로운 ? 연산자는 그에 따라 구문 분석해야 합니다. 해당 기능이 꺼져 있는 경우에만 파서에 이러한 연산자가 있는 공백이나 중괄호가 필요합니다. 이는 주요 변경 사항이며, 옵션이 설정되지 않은 한 일부 스크립트(정량할 수 없는 작은 숫자)는 중단됩니다(변수 이름을 허용하지 않으면 $IsIt을 방지해야 합니다. ?.tostring()은 스크립트의 첫 번째 오류이므로 스크립트는 위험하게 실행되지 않고 실패해야 합니다. 이상적으로는 포인트 릴리스에서는 발생하지 않아야 합니다(PowerShell이 ​​실제로 sem-ver를 사용하지 않는다는 것은 맞습니다. 하지만 여전히 좋은 원칙입니다)

{...}를 요구하는 문제는 타이핑의 불편함만이 아닙니다. 처음에는 그 필요성을 기대하지 않고 나중에 필요성을 잊어버리는 것(잠재적으로 미묘한 오작동과 함께)에 관한 것입니다. 너무 반 직관적입니다.

이것은 좋은 지적이며 실제로 ${...?} 에 대해 나를 짜증나게 하는 것입니다. {} 를 사용하는 것을 알고 있더라도 결국 잊어버릴 가능성이 크며, 이는 아마도 구문적으로 여전히 유효하기 때문에 처음에는 분명하지 않은 미묘한 버그를 초래할 수 있습니다. $var??='bar' 는 좋은 예이지만 일반적으로 간격에 대해 매우 조심합니다.

@jhoneill님 , 감사합니다. PowerShell에서 얼마나 많은 기호가 이중(삼중, ...) 역할을 하는지 잘 보여줍니다.
대부분의 경우 다음과 같은 이유로 모든 용도를 알고 나면 문제가 되지 않습니다.

• 다른 컨텍스트(예: 연산자로 * 대 와일드카드 문자로 * )
  
  
  
  • ? 대한 다른 컨텍스트에는 특정 수준의 추상화에서 실제로 공통점이 있습니다. Get-ChildItem | ? Target , $var?.Target , $? 에서 ? 를 생각할 수 있습니다. $? , $var ?? 'none' 모두 일종의 _질문_ 및 따라서 _테스트_ 또는 _조건부 행동_을 포함합니다.
  
  
• 합리적인 다형성 동작(예: + 문자열과 연결 수행).

문제가 있는 예는 & (호출 연산자 대 백그라운드 연산자)이며, 이는 _position_에 따라 다른 의미로 동일한 컨텍스트에서 사용됩니다.

변수 이름에 "?"가 포함된 경우 수정됩니다. "."가 포함된 이름처럼 중괄호가 필요합니다. 또는 "+" 또는 ":"

사실, 그리고 반복해야 합니다. 변수 이름에 ? 를 사용하는 기능은 사라지지 않지만 앞으로 {...} 를 사용해야 합니다. ${var?} = @{ foo=1 }; ${var?}?.foo

당신이 증명하듯이, 누군가가 ? 가 유효한 문자가 될 것이라고 예상하지 _아닌_ 현명하게 관점에서. 이러한 연산자에 대해 언어를 (상황적으로) 공백에 민감하게 만들었습니다. PowerShell은 일반적으로 공백을 구분하지 않기 때문에(최소한 한 줄은 허용되지 않습니다. . 는 정당한 예외입니다. ? 는 Where-Object 뒤에 공백이 필요한 gci|?target 는 작동하지 않음) 명령 이름 _do_는 공백으로 인수와 구분해야 합니다.

. 와 멤버 이름( $obj. foo ) 사이에 공백을 넣을 수 있다는 것은 여러 줄로 된 문장에서 주로 의미가 있습니다. . _앞에 공백 허용 :

# This does NOT work - the . must be *immediately after* the expression / member
(Get-Date)
  .ToUniversalTime()  
  .TimeOfDay

그렇게 할 수 있다는 것은 _next_ 라인에 | 를 배치하는 최근에 추가된 기능을 반영하는 것입니다:

 # Already works in PS Core
Get-Date
  | % ToUniversalTime
  | % TimeOfDay

그러나 이것은 . 로 시작하는 명령 이름과 . 시작하는 명령 이름과 . 를 사용하여 해결할 수 없는 모호성을 유발합니다. (예: 새 줄의 . foo 는 속성 액세스 또는 foo ( $env:PATH 에 있어야 함)라는 이름의 함수 또는 스크립트를 도트 소싱하는 명령 foo 수 있습니다. ; .foo 는 _command_의 이름일 수 있습니다.

@KirkMunro 의 여러 줄 연속 RFC는 _commands_가 여러 줄에 걸쳐 있도록 허용하는 데 중점을 두면서 다음으로 최상의 솔루션을 제공할 것입니다( https://github.com/PowerShell/PowerShell-RFC/pull/179#issuecomment -498734875 참조).

기본적으로 켜져 있는 실험 기능에 관해서: 다행히도 _preview_ 릴리스 - 릴리스 후보가 아님 - 이제 기본적으로 _모든_ 실험 기능을 켭니다. 그러나 Enable-ExperimentalFeature 를 _without_ -Scope 또는 -Scope CurrentUser 에서 활성화한 기능과 함께 실행한 적이 있는 경우 이는 지속적으로 무시된다는 점에 유의하십시오.

@mklement0 기본적으로 그 모든 것에 동의하지만, 당신이 거기에 있는 여분의 비트와 조각으로 인해 이 특정 토론을 약간

나는 ? 를 일반 변수 이름 문자로 계속 허용하는 것이 기껏해야 사용자에게 극도로 혼란스럽다는 데 동의합니다. 문자를 사용하면 갑자기 공백이 민감해지기 때문입니다. 역사적으로 적어도 변수 이름에는 _ever_가 없다고 생각합니다. 과거에는 공백을 구분했습니다.

그 모호성을 도입하는 것이 중요한 변경을 하고 ? 가 변수 이름에 사용되는 것을 허용하지 않는 것보다 더 큰 문제라고 생각합니다. 주요 변경 사항을 통해 작성자에게 구문이 더 이상 허용되지 않음을 경고하는 PSSA 규칙을 쉽게 작성할 수 있습니다. 그러나 그 반대는 그렇게 쉽게 사실이 아니며 주요 변경 사항과 달리 반드시 오류가 발생하지는 않습니다. 사용자가 자신이 하고 있는 일을 모른 채 실수로 잘못된 변수를 자동으로 참조하는 경우가 매우 쉽게 발생할 수 있습니다.

@PowerShell/powershell-committee에서 이에 대해 논의했으며 스크립트의 PowerShell 코퍼스를 분석했으며 물음표로 끝나는 변수 이름이 꽤 많이 사용되었습니다. 따라서 PowerShell 변수 이름 주위의 중괄호를 끊을 수는 없으며 변수 이름을 다른 문자(예: 문자열 내)와 구별하기 위한 기존 언어 기능입니다.

우리는 스크립트의 PowerShell 말뭉치를 분석했고 물음표로 끝나는 변수 이름의 사용이 꽤 있었습니다.

@SteveL-MSFT 감사합니다. 이 분석 결과를 공유해 주시겠습니까?

예, 일부 커뮤니티 구성원이 자체 분석을 수행했지만 그런 종류의 결과에 근접한 결과를 얻지 못했다는 것을 알고 있기 때문에 그 중 일부를 보고 싶습니다.

또한 사용된 결과와 방법을 보고 싶습니다. 어젯밤 내 컴퓨터에서 완료하는 데 거의 6시간이 걸렸던 AST를 사용하여 PowerShell Corpus 에 대한 자체 분석을 수행했습니다. Windows Defender가 파일을 격리하기 때문에 일부 파일을 구문 분석할 수 없습니다.

물음표로 끝나는 8개의 파일에서 11개의 고유한 변수 이름을 찾았습니다(8846번 나타난 $? 제외). 408,423개의 파일에서 총 1,895,983개의 고유 변수가 있었습니다. 즉, 말뭉치에 있는 모든 고유 PowerShell 변수의 0.0006%에 물음표로 끝나는 변수 이름이 있습니다.

다음은 8개의 파일과 11개의 고유 변수입니다.

File                 : C:\Temp\PowerShellCorpus\Github\alanrenouf_PowerActions\Kill-VM.ps1
QuestionMarkVars     : vParam?
QuestionMarkVarCount : 1

File                 : C:\Temp\PowerShellCorpus\Github\anthonywlee_PowerShell\Send_Notification.ps1
QuestionMarkVars     : To?
QuestionMarkVarCount : 1

File                 : C:\Temp\PowerShellCorpus\Github\aspear_My-PowerCLI-scripts\my-labotomize-vms.ps1
QuestionMarkVars     : vParam?
QuestionMarkVarCount : 1

File                 : C:\Temp\PowerShellCorpus\Github\jlundstrom_Scripts\Powershell\7Zip SFX Creator\Build.ps1
QuestionMarkVars     : Title?
QuestionMarkVarCount : 1

File                 : C:\Temp\PowerShellCorpus\Github\pslaughter_Working\Setup-Host.ps1
QuestionMarkVars     : HostIp?
QuestionMarkVarCount : 1

File                 : C:\Temp\PowerShellCorpus\Github\stevenayers_PowerShell-Scripts\Random Functions\Add-OutlookConferenceRegionNumber.ps1
QuestionMarkVars     : {key1?, key2?, key3?, key4?}
QuestionMarkVarCount : 4

File                 : C:\Temp\PowerShellCorpus\Github\unixboy_powershell-stufff\stopvm.ps1
QuestionMarkVars     : vParam?
QuestionMarkVarCount : 1

File                 : C:\Temp\PowerShellCorpus\PowerShellGallery\PsHg\0.6.2\PsHg.psm1
QuestionMarkVars     : PsHg?
QuestionMarkVarCount : 1

다음은 보고서를 생성하는 데 사용되는 스크립트입니다.

Get-ChildItem -Path C:\Temp\PowerShellCorpus -Include *.ps1, *.psm1 -File -Recurse | ForEach-Object -Parallel {
    try {
        $content = $PSItem | Get-Content

        $ast = [System.Management.Automation.Language.Parser]::ParseInput($content, [ref]$null, [ref]$null)
        $variables = $ast.FindAll({$args[0] -is [System.Management.Automation.Language.VariableExpressionAst ]}, $true)

        # First query because I forgot to exclude $? variables
        # $nonQuestionMark = $variables | Where-Object VariablePath -notmatch '\?$' | Select-Object -Unique
        # $QuestionMark = $variables | Where-Object VariablePath -match '\?$' | Select-Object -Unique

        $nonQuestionMark = $variables |
        Where-Object VariablePath -notmatch '\?$' |
        ForEach-Object { $_.VariablePath.UserPath.ToString() } |
        Select-Object -Unique

        $QuestionMark = $variables |
        Where-Object { $_.VariablePath -match '\?$' -and $_.VariablePath.UserPath -ne '?' } |
        ForEach-Object { $_.VariablePath.UserPath.ToString() } |
        Select-Object -Unique

        $output = [pscustomobject]@{
            File = $PSItem
            QuestionMarkVars = $QuestionMark
            QuestionMarkVarCount = $QuestionMark.Count
            NonQuestionMarkVars = $nonQuestionMark
            NonQuestionMarkVarCount = $nonQuestionMark.Count
        }

        $output
    }
    catch {
        throw
    }
}

이 보고서를 생성하는 데 사용된 방법에 문제가 있으면 알려주십시오. 다음은 감사를 테스트하는 데 사용되는 예제 스크립트입니다.

$abc = 'test'
$isAwesome? = $true
$?

$test = {
    $?
    $isabc? = { $adce? = 'test' }
    ${def?} = 123
    ${is a bad var name?} = $isabc?
}

결과:

File                    : C:\temp\variable.ps1
QuestionMarkVars        : {isAwesome?, isabc?, adce?, def?, is a bad var name?}
QuestionMarkVarCount    : 5
NonQuestionMarkVars     : {abc, true, test}
NonQuestionMarkVarCount : 3

수학시간에 '작품 보여주세요' 라는 말처럼 😄

훌륭한 탐정 ,

난 당신이 잠재적 형태로 주어진, 더 많은 경우를 제거 할 수 있다고 생각 ${...} 제안 된 변경과 함께 계속 작동합니다 - 예를 들어, 그것은 단지의 $isAwesome? 우리가하지에 대해 걱정할 필요가 ${isAwesome?}

예제 파일:

$variables.Extent.Text.Where({ $_ -match '(?<!\$)\?$' }) | Select-Object -Unique

우리는 다음을 얻습니다.

$isAwesome?
$isabc?
$adce?

즉, ${def?} 및 ${is a bad var name?} 는 고려할 필요가 없습니다.

추신: $PSItem | Get-Content -Raw 를 사용하여 전체 스크립트를 단일 문자열로 읽는 것이 더 나을 것입니다.

@mklement0 맞습니다 . 스크립트가 중괄호 표기법이 있는 변수를 모두 제외하지 않도록 게시 직전에 해당 사례를 추가했습니다.

권장 사항으로 스크립트를 업데이트한 후 테스트 파일은 예상대로 다음과 같은 출력을 생성합니다.

File                    : C:\temp\variable.ps1
QuestionMarkVars        : {isAwesome?, isabc?, adce?}
QuestionMarkVarCount    : 3
NonQuestionMarkVars     : {abc, true, test}
NonQuestionMarkVarCount : 3

그 8개 파일에서 업데이트된 스크립트를 실행했는데 그 중 어느 것도 중괄호 표기법을 사용하지 않았으므로 결과는 여전히 11개의 고유 변수가 제안된 변경 사항에 영향을 받습니다.

업데이트된 스크립트:

Get-ChildItem -Path C:\Temp\PowerShellCorpus -Include *.ps1, *.psm1 -File -Recurse | ForEach-Object -Parallel {
    try {
        $content = $PSItem | Get-Content -Raw

        $ast = [System.Management.Automation.Language.Parser]::ParseInput($content, [ref]$null, [ref]$null)
        $variables = $ast.FindAll({$args[0] -is [System.Management.Automation.Language.VariableExpressionAst ]}, $true)

        $nonQuestionMark = $variables |
        Where-Object VariablePath -notmatch '\?$' |
        ForEach-Object { $_.VariablePath.UserPath.ToString() } |
        Select-Object -Unique

        $QuestionMark = $variables |
        Where-Object { $_.VariablePath -match '\?$' -and $_.VariablePath.UserPath -ne '?' -and $_.Extent.Text -match '(?<!\$)\?$' } |
        ForEach-Object { $_.VariablePath.UserPath.ToString() } |
        Select-Object -Unique

        $output = [pscustomobject]@{
            File = $PSItem
            QuestionMarkVars = $QuestionMark
            QuestionMarkVarCount = $QuestionMark.Count
            NonQuestionMarkVars = $nonQuestionMark
            NonQuestionMarkVarCount = $nonQuestionMark.Count
        }

        $output
    }
    catch {
        throw
    }
}

감사합니다. @ThomasNieto - 백분율을 0.0005%로 낮출 수 있기를 바랐습니다... (농담).

그래서 위원회는 다른 것을 사용해야 했을까요? - 말뭉치.

따라서 당면한 문제를 결정하는 것 외에도 다음과 같은 질문이 발생합니다. 공개적으로 사용 가능한 말뭉치를 업데이트해야 합니까? 공식적으로 유지 관리됩니까(현재 2017년 7월 26일자)?

@SteveL-MSFT, 설명해 주시겠습니까?

@mklement0 반올림해서 조금 더 나아진 느낌을 원하시면 실제로는 0.00058% 😄

https://github.com/PowerShell/PowerShell-RFC/pull/223#discussion_r318340339 @adityapatwardhan 은 내가 사용한 것과 동일한 공개 말뭉치를 사용하여 분석을 수행했으며 물음표로 끝나는 변수로 62%를

링크된 댓글을 보면 _이름 에 ? 있는 모든 변수 중_ 62%가 이름의 _last_ 문자로 ? 가 있다고 @adityapatwardhan 이 말하는 것 같습니다.

대조적으로 (중괄호가 없는) ? 변수의 실제 보급률(전체 변수 사용 비율)에 대한 분석이 훨씬 더 적절해 보입니다.

이 시점에서 위원회는 "우리는 원하지 않는다"고 말하는 것처럼 들립니다. 그렇다면 이 기능이 결과적으로 투박하고 사용되지 않을 것이라면 왜 이 기능을 가지고 있습니까?

@ThomasNieto 마찬가지로 이러한 문제와 관련하여 어딘가에서 분석을 수행했으며 비슷한 결과를 얻었습니다.

@mburszley 분석해 주셔서 감사합니다. 작년에 얻은 결과를 확인하기 위해 다른 방법(ast vs regex)을 사용하고 싶었습니다.

@mburszley , 하지만 다시:

위원회는 단지 "우리는 원하지 않는다"고 말하고 있습니다

이것이 실제로 _명목_ 결정이라면(실제 사용 분석에 근거하지 않은) 특히 _명시된_ 이유가 그러한 분석의 근거라는 점을 감안할 때 커뮤니티 전체에 좋은 징조가 아닐 것입니다.

따라서 우리는 위원회에 결정의 기반이 된 실제 사용 분석을 보여주거나 분석이 미흡했음을 인식하고 결정을 재고할 기회를 주어야 합니다.

https://github.com/PowerShell/PowerShell/issues/11379#issuecomment-566756120 에서 내 제안은 어떻습니까?

$obj?.Method() 가 기본적으로 $<var i="9">obj</var> ?. <var i="12">Method</var>() 로 작동하고 $<var i="14">obj?</var> . 되돌아가도록 하는 것이 좋습니다. <var i="17">Method</var>() $<var i="19">obj</var> 가 범위에 없지만 $<var i="21">obj?</var> 는 있고 #requires ‑Version 는 v7+가 아닌 경우입니다.

나는 그것이 이전 버전과의 호환성 문제의 대부분을 해결할 것이라고 기대합니다.

@ThomasNieto

@mklement0 이 맞습니다. ? 사용하는 변수 중 62%가 마지막에 사용한다는 뜻입니다.

여기 주석에 표시된 결과에서 ? 사용하는 모든 변수가 끝에 사용하는 것 같습니다. 따라서 획기적인 변경을 제안합니다.

{..} 대한 요구 사항이 제거되면 스크립트는 여전히 구문 분석되지만 의미 체계는 달라져 제 생각에는 매우 위험합니다.

물론... 하지만 분석 결과 말 그대로 거의 아무도 사용하지 않는 것으로 나타났습니다.

다른 브레이킹 체인지와 마찬가지로 발표될 수 있고, 잠시 실험적인 기능으로 도입된 다음, 문서화되어 안정화될 수 있습니다.

식별자 문자로 ? 가 실제로 원격으로 상당한 수의 경우에 사용되지 않을 때 난해한 구문을 권장할 이유가 없습니다.

{..}에 대한 요구 사항이 제거되면 스크립트는 여전히 구문 분석되지만 의미 체계는 달라져 제 생각에는 매우 위험합니다.

사람들이 C/C++/C#에서 하는 방식으로 ?. 하고 아무 표시도 없이 잘못된 결과를 얻는 것에 대해 걱정하지 않습니까? 예를 들어:

PS> $res = "My length is 15"
PS> $res?.Length
0

물론, strict-mode는 이것을 찾을 수 있지만 많은 사람들이 strict 모드를 사용하는지 모르겠습니다. 따라서 아주 적은 비율의 스크립트가 깨지는 것을 방지하기 위해 많은 사람들이 ?. 사용에 실패하도록 설정하는 것 같습니다. 나는 트레이드 오프에 대해 미친 것이 아닙니다. 그렇긴 한데, 극소수라도 사람을 해치지 않으려는 마음은 충분히 이해합니다.

PowerShell에는 더 이상 실험적 상태가 아니지만 기본적 으로 켤 준비가 되지 않은 기능에 대해 Enable-ExperimentalFeature Enable-PSFeature 에 해당하는 것이 필요할 수 있습니다. $?.GetType() 와 같은 코드로 실행되는 스크립트의 경우 앞으로 이것이 중단될 것이며 대신 ${?}.GetType() 를 사용해야 한다는 경고를 방출하기 시작할 수 있습니다. 개별 스크립트는 #requires -version 7.1 -feature PSNullConditionalOperators 기능을 활성화할 수 있습니다. 그러면 PS 8이 출시될 때마다 이 기능이 기본적으로 활성화될 수 있습니다.

@rkeithhill 의 예시는 바로 본론으로 넘어갑니다.
현재 PowerShell 작동 방식에 대해 알고 있는 것은 잠시 잊으십시오. 당신이 볼 때

PS> $res?.Length

_name, operator, name_처럼 보입니다. 물론 그렇습니다.
어느 쪽이 더 이해가 될까요? _"?" operator_ 또는 _"의 일부입니까?" name-element_ 의 일부입니까?
이러한 연산자가 필요한 경우(그리고 "PowerShelly가 아닌" 것으로 생각함) 잘못 사용되는 것과 약간의 파손 사이에서 선택합니다.

변수 이름에 특정 [합법] 문자를 사용하는 것은 나쁜 스타일이라고 말하기 위해 psScriptAnalyzer _now_에 규칙을 적용하기 시작했습니다.

나는 Enable-feature 좋아하지 않습니다. 누군가 사용하고 싶은 것을 만들기 위해 스크립트에 넣고 새 스크립트 다음에 실행하면 이전 스크립트가 중단되지만 나머지 시간에는 작동합니다. Y가 엄격 모드를 켜고 X가 꺼짐에 의존하기 때문에 _타사 스크립트 X가 스크립트 Y_를 실행한 후 실패하는 것을 보았습니다. 두 스크립트의 저자는 내 나쁜 책에 있습니다.

변수 이름에 특정 [합법] 문자를 사용하는 것은 좋지 않은 스타일이라고 말하기 위해 이제 psScriptAnalyzer에 규칙을 적용하기 시작합니다.

문제는 다음과 같습니다. PowerShell이 ​​변수를 토큰화하는 방식을 변경하면 PSScriptAnalyzer에서도 변수를 다르게 인식합니다. $res? 와 같은 변수가 있는 경우 다음과 같이 살펴봅니다.

{
$res?.Length
}.Ast.EndBlock.Statements[0].PipelineElements[0].Expression.Expression.VariablePath.UserPath

당신에게 준다

res?

그러나 PowerShell이 ​​구문 분석되는 방식(예: 7.2)을 변경하면

이제 PSScriptAnalyzer는 ? 볼 수 없습니다. 왜냐하면 이것은 더 이상 변수 이름의 일부가 아니기 때문입니다(정의상, 테스트하려는 변경 사항이기 때문에). 이는 PSScriptAnalyzer가 PowerShell 모듈이고 PowerShell에서 제공되는 것과 동일한 파서를 재사용하기 때문입니다. (그리고 다시 구현하려고 하면 완전히 유지 관리할 수 없고 재앙을 초래할 수 있습니다.)

동일한 진단을 제공하기 위해 새로운 7.2 논리를 테스트하기 위해 PSScriptAnalyzer를 조건부로 컴파일하고 완전히 새로운 어셈블리를 제공하는 것과 같이 이 문제를 해결할 수 있는 방법이 있습니다. 그러나 그런 다음 다소 미학적인 시나리오를 제공하기 위해 모든 곳에서 복잡성을 증가시켰습니다(또는 테스트 표면을 줄였습니다).

설상가상으로 AST에 의존하는 다른 모든 도구는 PSScriptAnalyzer가 있더라도 이러한 종류의 복잡성을 유지할 능력이 없습니다. AST 대상 도구를 구축하는 대부분의 사람들은 완벽한 정확성을 위해 PowerShell의 개별 부 버전에 대해 컴파일하지 않을 것입니다. 그들은 아마도 어떤 버전에서도 오류가 아니기 때문에 그러한 작은 주요 변경 사항에 대해 알지 못할 것입니다. 그것은 한 행동이 조용히 다른 행동으로 바뀌는 가장 교활한 형태의 변화입니다.

이것이 기본적으로 이와 같은 파서/토키나이저 수준의 변경을 더 위험하게 만드는 것입니다. PSScriptAnalyzer조차도 올바르게 서비스하기 위해 뒤로 구부려야 합니다. 즉, 이러한 번거로운 변경에 대해 무게를 달아야 합니다.

@rjmholt , 저는 우리 모두가 이와 같은 변경이 _원칙적으로_ 얼마나 까다로운지 알 수 있다고 생각하지만, 이 특별한 경우에는 _실제로는 중요하지 않으며 PSSA 규칙이 필요하지도 않다고 생각합니다.

• @ThomasNieto 의 분석 에 따르면 - 말뭉치가 모든 PowerShell 코드를 대표한다고 믿는다면 _거의 아무도 이름이 ? 끝나는 변수를 사용하지 않습니다 _.

• 내가 추측한다면, 대부분의 사람들은 그러한 변수 이름을 사용하는 것을 _생각_하지도 않을 것입니다. 왜냐하면 그들은 (저를 포함해서) 그들이 작동할 것이라고 기대하지 않을 것이고 아마도 자동 $? 변수는 구성됩니다(이름이 bash 와 같은 POSIX 호환 쉘에서 동일하게 예외임).

  • 실제로 @ThomasNieto 의 분석을 자세히 살펴보면 나열된 8 파일 중에서 다음을 알 수 있습니다.
    
    
    
    • 5 에는 _false positives_만 포함됩니다. 즉 "Are you sure you want to kill $vParam?" 와 같은 _strings_ 내부에서 사용하는 변수 - 실제로 이러한 사용은 _깨져_ 있으며 스크립트 작성자가 ? 를 기대하지 _하지_ 않았음을 나타냅니다. 변수 이름의 일부입니다.
    
    
    • 해당 파일 중 2 는 더 이상 공개적으로 사용할 수 없습니다.
    
    
    • 그 중 _1_만 ? - $key1? ) 로 선의의 사용이며 , 따라서 제쳐두고 멤버 액세스 연산자와 _not_ 결합됩니다. , . /cc @stevenayers.
    
    

위의 내용을 기반으로 하면 이것은 교과서적인 버킷 3: 가능성이 없는 회색 영역 변경으로 생각됩니다. 따라서 _수용할 수 있는_ - 그리고 이 변경의 _이점_이 설득력 있게 논의되었다고 생각합니다.

_문서화_ 행동의 변화(이유가 있는)로 충분해야 합니다.

물론이야:

1. 이것은 (a) 분석이 정확하고 (b) 공개적으로 이용 가능한 말뭉치가 대표성이 있다는 것을 전제로 합니다.

2. "물음표로 끝나는 변수 이름이 꽤 많이 사용되었다"는 위원회의 주장과 완전히 상반됩니다(물론 이러한 변수 이름이 {...} 묶이지 않은 경우에만 문제가 됩니다).

1.이 사실이라는 가정하에 진행하면(2를 지원하는 것을 듣지 못했습니다.) 두 가지 옵션이 있습니다.

• 밴드 원조를 벗어 버리고 단순히 허용 ? 로 묶여 않는 변수 이름의이 향후 {...} (의 명백한 제외하고 $? ) - 이것은 하고서을 깰 것 현재 그것에 의존하는 스크립트의 비율.

  • 즉, . 나 ? ( $key1??'else' ) 또는 삼항 표현식( $key1?1:0 )이 뒤따르지 않는 $key1? 와 같은 것입니다 $key1??'else' _parser error_가 발생합니다.
    
    
    
    • null-coalescing 및 3항 연산자 예제에서 알 수 있듯이 이 변경으로 인해 혜택을 볼 수 있습니다. 현재 _space_ - $key1 ?1:0 / $key1 ??'else' - 또는 {...} - ${key1}?1:0 / ${key1}??'else'
    
    
  • _expandable strings_ 내부에서 ? 는 더 이상 (비 {...} -enclosed) 변수 이름의 일부로 간주되지 않으므로 실제로 "Are you sure you want to kill $vParam?" 와 같은 문자열을 잘못 사용한 기존 스크립트를 _수정_합니다

• 우리가 정말로 기존 스크립트의 아주 작은 부분을 깨뜨리는 것을 피해야 한다고 느낀다면 @ExE-Boss가 제안한 논리를 _고려할 수 있지만

@SteveL-MSFT

9월 커뮤니티 콜(https://aka.ms/PSCommunityCall, 이 글을 쓰는 현재)에서 이 문제에 대해 논의해 주셔서 감사합니다. https://github.com/PowerShell/PowerShell-RFC/issues/260 에서 토론 주제에 대한 사전 요청에서 @ThomasNieto 의 제안을 기반으로 46:00부터 시작합니다.

(녹음의 관련 부분에 대한 직접 링크를 제공하고 싶었지만 YouTube에 게시되고 https://aka.ms/PSCommunityCall에 링크될 때까지 기다려야 합니다.)

녹음 내용에 대한 귀하의 의견을 바탕으로:

• 이 문제를 다시 방문할 의사가 있음을 나타내면 이 문제를 다시 열고 Review - Committee 로 다시 태그를 지정하십시오.

• 중괄호로 변수 이름을 묶는 것은 이미 존재하는 기능이며 사람들은 _미학적_ 이유로 이 경우에 사용해야 하는 것에 반대합니다.

  • 여기 있는 누구도 {...} _가능하고_ 때로는 _반드시_ 변수 이름을 명확하게 하는 데 사용된다는 것을 _모르는__ 사람이 없다고 생각합니다.
  • 이것은 또한 _미학에 관한 것이 아니라 _이 경우에 {...} 를 사용해야 할 것으로 예상하지 않기 때문에 _조용히 실패하는 방식으로 _예상되는 동작을 얻지 못하는_에 관한 것입니다. 두 번째 문제는 타이핑의 불편함입니다.

깃허브

PowerShell/PowerShell-RFC

PowerShell 에코시스템의 설계 변경 및 개선 사항에 대한 커뮤니티 피드백을 위한 RFC(Request for Comments) 문서 - PowerShell/PowerShell-RFC

마이크로소프트 팀즈

대화에 참여

나는 이 문제(지금은 폐쇄된 상태인 것처럼 보입니다)가 균열을 통해 떨어질까 우려합니다. 그래서 #14025를 다시 방문하도록 상기시키기 위해 열었습니다. 관심이 있는 모든 사람이 거기에서 지원을 표시하도록 초대합니다.