흥미 롭군. 저는 .ps1 의 1 가 PowerShell 스크립트에 일종의 의미 체계 버전 관리를 추가하여 스크립트가 가능한 주요 변경 사항에 적용되었는지 여부를 나타내는 데 사용되는 이유를 항상 궁금해했습니다.

새로운 .NET 개념을 채택하지 않은 PowerShell의 기술적 부채라고 생각하는 문제를 해결하는 데 비용이 많이 듭니다.

• 제네릭 메서드의 형식 매개 변수에 대한 언어 구문 # 5146

• 유형 시스템에 자동으로 표시되도록 Extension Methods 에 대한 엔진 지원 (_compiled_ .Net 언어 에서처럼) # 2226

• 비동기 API # 6716 (및 RFC )에 대한 언어 지원

몇 가지 유감스러운 기능이 있습니다.

• 형식 지정 개체를 출력하는 cmdlet 대신 형식 힌트 (예 : @KirkMunro 의 FormatPx )를 기반으로 할 수 있습니까? # 4594 # 4237 # 3886

• 속성 제공자가 어떻게 작동 할 수 있는지에 대한 데모처럼 느끼지 않고 레지스트리 제공자를 _content_ 기반으로 정규화 하시겠습니까? # 5444

• PSProvider를 깊이 리팩터링하여 더 쉽게 작성할 수 있습니까? "SHiPS"에 도달하고 마침내 사람들이 사용할 의사가있는 공급자를 작성할 수있는 방법을 제공하는 것은 두 가지 추상화 계층이 필요하다는 점은 부끄러운 일입니다.

더 큰 질문은 어떻습니까?

우리는 "많은 방법이 더 낫다"라는 접근 방식을 재고하고 "성공의 구덩이"접근 방식을 연구 할 의향이 있습니까? 내 말은, "쉬운 방법"으로 간주되지만 근본적으로 더 나쁜 기능을 제거하여 "올바른 방법"만 사용하기를 원할까요? 예 :

• CmdletBinding을 항상 사용하도록 설정
• @ () 표기법은 List[PSObject] 의미합니다.
• @ {}를 Dictionary[PSObject, PSObject] (또는 Dictionary[string, PSObject] 😲)로 지정
• _Process_를 기본 블록으로 설정
• 어쩌면 _ValueFromPipelineByPropertyName_을 기본값으로 만들 수도 있습니다 ;-)

모든 훌륭한 제안, @Jaykul.

@() 표기법을 다시 만드는 것은 List[PSObject] 의미합니다. : 저는 우리가 이것을 더 취하고 효율적으로 확장 가능한 컬렉션 유형을 PowerShell의 기본 컬렉션 유형으로 사용할 수 있으므로 [object[]] 어디에서나 사용할 수 있습니다. 현재 (그리고 내부적으로뿐만 아니라 컬렉션을 반환 할 때도 사용되며, 유형 변환 성능 저하없이) + 사용에는 문제가 있지만 @PetSerAl은이 를 처리하기 위해 사용자 지정 목록 구현을 제안했습니다 .

Process {} 를 함수의 기본 블록으로 다시 만듭니다. 제쳐두고 : 현재 Filter 이 수행하는 작업이지만-묵시적- Process 블록 및이 함수 변형으로 제한됩니다. 겉보기에는 실제로는 잡히지 않은 것 같습니다. Function 의 맥락에서 두 가지를 통합하는 것이 나에게 의미가 있습니다.

재미있게도, 지금 Azure PowerShell 커뮤니티 스탠드 업 호출에서 그들은 AzureRm에서 크로스 플랫폼 (별도의 AzureRm.Core 없음)이고 모든 명령 접두사가 AzureRm에서 Az로 변경된 새로운 Az 모듈로 이동할 것입니다. 두 사람은 잠시 동안 나란히있을 것이지만 새로운 명령 세트로 이동하고 있습니다.

너무 나쁜 PowerShell은 아직 Windows PowerShell과 나란히 실행되는 새 실행 파일을 만들 기회가 없었지만,이를 끌어 내리는 레거시 문제에서 벗어날 수 있습니다.

우리가 그것을 위해 가면 어떻게 될지 상상해보십시오.
현실적으로 말하면 '후회 없음'버전을 내놓는 데 최소 6 개월의 집중적 인 노력이 필요하며이를 반복하려면 6 개월이 더 걸립니다. 그런 다음 타사 모듈도 이에 맞게 조정해야이 버전이 유용합니다. 합리적 적용 범위를 확보하는 데 6 개월 이상이 소요됩니다 (일부 모듈은 절대 적용되지 않음을 명심하십시오). 지연 및 예상치 못한 문제 등 ... 그래서, 한 번에 모든 기술 부채를 한 번에 없앨 수 있다는 것은 희망적인 생각 일 뿐이라고 생각합니다 (이전 버전을 유지하는 것이 아니라 여전히 개발 중입니다).

그런 버전이 존재하기를 바랬던만큼 한 번에 하나씩 만 천천히 접근 할 수 있다고 생각합니다. v6에서는 이미 많은 주요 변경 사항이 허용되었지만 한 버전에 너무 많은 주요 변경 사항이 포함되어 있으면 기존 스크립트 / 모듈을 업그레이드하기에는 너무 복잡해질 것이라고 생각합니다. 가장 가치있는 주요 변경 사항에 대해 논의하는 것은 좋지만 LTS 버전의 pwsh가 없을 때까지 기존의 주류 버전과 병행하여보다 실질적인 변경 사항이있는 pwsh의 두 번째 기차를 고려할 때라고 생각하지 않습니다.

@bergmeister 동의합니다. 그러나 핵심 경로에 대한 비교적 작은 변경조차도 채택을 심각하게 방해 할 수 있습니다. 파이썬 3을보세요. 실제로 따라 잡는 데 10 년이 걸렸습니다. 훨씬 더 큰 변화로 인해 Perl 6이 우위를 차지하는 데 걸리는 시간을 누가 알 수 있습니까? 방법과 용도로 인해 정기적으로 물건을 부수십시오.

Python 3은 확실히 공포의 쇼입니다. 아직 실제로 사용 되었습니까? 아직 2.7을 실행 중이며 곧 업그레이드 할 계획은 없습니다. 하지만 최근에도 Perl 6에 대해 많이 듣지 못했습니다 ...

파이썬에서 배울 수있는 교훈은 엔진의 버전 변경에서 언어의 주요 변경 사항을 분리하는 것입니다. 가설 적으로 PS 7 엔진은 중단없는 변경 모드에서 이전 스크립트 (.PS1) 파일을 계속 실행할 수있는 반면, 스크립트가 7 인식 (예 : .PS7 확장자)으로 표시되면 업데이트되었다고 선언 할 수 있습니다. 실행하려면 최소한 PS 7이 필요합니다. 이해가 되길 바랍니다.

아마도 최고의 성공 사례는 JavaScript / TypeScript / Babel 일 것입니다. 트랜스 파일러 (소스 맵 지원 포함)는 언어 진화를위한 방법처럼 보입니다.

자바 스크립트는 특별한 경우입니다. 당신은 그것에 거의 집착했기 때문에 트랜스 파일이 정말로 유일한 옵션입니다. Typescript는 확장 기능이있는 "단지"Javascript이므로 사람들이 쉽게 채택 할 수 있습니다. 모든 자바 스크립트 프로그램은 타이프 스크립트 프로그램이므로 가지고있는 것으로 시작하고 거기에서 주석을 추가하기 만하면됩니다. 반면에 Dart는 자체 언어이지만 자바 스크립트 또는 Chrome의 기본 런타임으로 변환됩니다 (적어도 한 시점에서 계획이었던 것입니다). Dart는 자체 언어이기 때문에 Google 외부에서 많이 채택되지 않은 것 같습니다.

뿡 빵뀨

Python 3은 확실히 공포의 쇼입니다. 아직 실제로 사용 되었습니까?

필자는 지난주에 저자가 Python 3에 대해 임계 값을 달성했다고 주장한 기사를 읽었습니다. 모든 핵심 모듈을 사용할 수 있고 이제는 사람들이 이주하는 사람들이 있습니다. 우리는 보게 될 것이다..

흥미 롭군. 나는 항상 .ps1의 1이 PowerShell 스크립트에 일종의 의미 론적 버전 관리를 추가하는 데 사용되어 스크립트가 가능한 주요 변경 사항에 맞게 조정되었는지 여부를 나타낼 수 있도록하는 이유를 궁금해했습니다.

WRT .ps1 , 언어가 완전히 잘못되어 런타임에 치명적인 변경이 발생하여 이전 버전의 스크립트가 작동하지 않을 경우 확장을 변경할 수있는 권한이 있습니다. 그러나 확장을 변경하면 생태계의 많은 것들이 확장에 묶여 있기 때문에 엄청난 작업 더미로 이어집니다. 그래서 가볍게 할 일이 아닙니다. 물론 Windows의 일부이기 때문에 확장 기능을 포크해도 두 버전을 모두 유지해야합니다 (Python 2/3과 비슷 함).

@bergmeister :

유효한 우려 사항이지만 다음과 같은 정신을 가지고 있습니다.

가장 가치있는 주요 변경 사항에 대해 논의하는 것이 좋습니다.

염두에두고있는 것을 공유하십시오.

천천히 한 번에 하나씩 변경

호환되지 않는 변경에 대한 (어휘 적으로 범위가 지정된) 옵트 인 메커니즘이 해결책이지만 두 가지 사항에 대해 우려합니다.

• 단편적인 소개는 어떤 기능에 어떤 버전이 필요한지 아무도 기억하지 못하게 할 수 있습니다. Perl (v5-)이 떠 오릅니다.

• 코드베이스가 커지고 유지 관리가 어려워지고 그 결과 바이너리가 똑같이 커져서 (적어도) 시작 성능이 저하됩니다.

나는 전에 말했었다 : 나에게 이것은 단지 예감 일 뿐이다. v6 GA는 유닉스 세계에서 채택을 방해 할 수있는 충분한 짐을 전달하면서 변화를 깨는 것에 만족하지 않는 노인들을 만드는 불행한 타협이었다.

즉, Unix [와 유사한] 세계에서 PowerShell의 상대적인 젊음을 감안할 때 호환되지 않는 변경을 통해 문제를 해결하려는 의지가 더 많을 것입니다. @BrucePay가 언급했듯이 Windows PowerShell은 어쨌든 유지 관리해야하며 이전 버전과의 호환성을위한 안전한 피난처로 남아있을 수 있습니다.

나는 그러한 획기적인 변화의 부정적인 결과의 규모가 이미 다루어 졌다고 생각하며, 대부분의 요점에 동의합니다. 더 큰 맥락에서 이러한 변화가 애초에 상당한 이점을 가져다 줄지 의심스러워서이 글을 쓰고 있습니다. 적어도 내가 PowerShell을 사용하는 방식에 대해서는.

OP에는 다음 문이 포함됩니다.

한편, 피할 수없는 부산물은 예외를 암기해야하는 기술적 부채의 축적이며 신규 이민자에게는 장벽이되었습니다.

이 진술의 내포 된 전제는 이러한 다양한 주요 변경 사항을 적용하면 예외를 암기하는 부담을 덜어 준다는 것 같습니다. 실제로 그것은 큰 결과가 될 것입니다. 그러나 나는 그것이 결과가 될 것이라고 회의적입니다. PowerShell의 동작은 의도적으로 풍부합니다. 이것은 표현력이 있고 예측할 수 없게 만듭니다. 표현력과 예측 가능성은 적어도 내가 익숙한 언어 사이에서 서로 불리하게 작용하는 것 같습니다.

위에서 언급 한 많은 주요 변경 사항이 경우에 따라 예측 가능성을 다소 향상시킬 수 있다는 데 동의하지만 언어의 예측 불가능하고 놀라운 측면이 많이 남아있을 것입니다. PowerShell을 작성하는 데 몇 년을 보냈음에도 불구하고, 저는 설계 상으로 보이며 아마도 변경해서는 안되는 PowerShell 동작에 여전히 자주 놀랐습니다. 최근 떠오르는 몇 가지 예는 다음과 같습니다.

• [scriptblock] 인수의 조건부 지연 바인딩 (# 6419)
• 정확히 암시 적 열거가 발생하는 경우 (# 5832)
• 매개 변수 바인딩 중 [AutomationNull]::Value 에서 $null (# 6357 관련됨)
• 파이프 라인의 제어 흐름에 대한 break 및 continue 의 영향 (# 5811)
• $null ( SO )를 표시하면 어떻게 되나요?
• 세션 상태에서 스크립트 블록을 사용하는 것이 $_ ( SO 1 , SO 2 )에 미치는 영향

나는이 예제들이 내가 아직 발견하지 못한 다른 많은 신중하게 디자인되었지만 놀라운 뉘앙스의 작은 부분에 불과할 것이라고 기대합니다. 이 예를 선택했습니다.

1. PowerShell에서 개선 할 수없는 동작을 나타냅니다.
2. PowerShell을 읽거나 쓸 때 모든 의미를 안정적으로 발견 할 수는 없습니다.

이건 괜찮아요. 놀라운 PowerShell 동작의 압도적 대부분은 PowerShell을 사용한 성공에 지속적인 영향을 미치지 않습니다. 놀라운 동작은 거의 항상 개발 중에 테스트를 통해 즉시 포착됩니다. 나는 빠져 나가는 것들로부터 배우고 그것을 사용하여 테스트 전략을 개선합니다. 이러한 놀라운 행동이 제거 될 수있는 종류이든, 남아 있어야하는 종류이든 상관없이 이는 사실입니다.

위에서 제안 된 주요 변경 사항이 적용되었는지 여부에 관계없이 PowerShell은 테스트 범위를 크게 줄일 수있을 정도로 예측할 수 없게 될 것입니다. 다시 말해, 제가 PowerShell을 사용하는 방식에서는 위에서 제안한 주요 변경 사항을 적용하여 가능한 이점이 많지 않다고 생각합니다.

(BTW, 직접이 질문을 해주신 @ mklement0 에게 감사드립니다. 이것은 한동안 제 마음 속에있었습니다. 모두가 자신의 작품을 말할 수있는 기회를 보게되어

감사합니다, @ alx9r.

_intrinsic_ complex와 _extrinsic_ complex를 구별하는 것이 중요하다고 생각합니다.

• _Intrinsic_ 복잡성은 구현되는 개념의 고유 한 복잡성에서 비롯됩니다. PowerShell의 경우에는 두 가지 기본 소스가 있습니다. _internal_ 새로운 패러다임 도입 (객체 기반 파이프 라인)과 두 개의 별개 세계 (셸 구문 및 프로그래밍 언어 구문)를 결합하는 복잡성 ), _external_ 복잡성은 여러 이질적인 외부 세계와의 인터페이스로 인한 것입니다.

  • 본질적인 복잡성은 개념과 기능을 적절하게 문서화하고 _names_도 부여하여 관리합니다.

  • 6419가 대표적인 예입니다. 강력하고 널리 유용한 기능이 그 밑에 있지만 ~ 현재 내가 아는 한 전혀 문서화되지 않았으며 확립 된 이름도 없습니다 ~; https://github.com/PowerShell/PowerShell-Docs/issues/2338 참조 [_delay-bind_ 스크립트 블록으로 문서화되었으므로]

  • _member enumeration_ 기능은 유사하게 확립 된 이름과 집중된 문서가 없습니다. https://github.com/PowerShell/PowerShell-Docs/issues/2198 참조

    • 멤버 열거의 _extrinsic_ 측면은 # 6802에서 설명합니다.

  • 5832는 적절한 개념 문서를위한 또 다른 후보입니다.

    • 그러나 현재 동작의 두 가지 _extrinsic_ 측면을 발견했습니다. 모든 스칼라에 .Count 뿐만 아니라 .Length 속성 및 매개 변수 바인딩 열거 동작이 파이프 라인 / 연산자와 미묘하게 다릅니다. 행동 .

• _Extrinsic_ 복잡성은 유출 된 추상화와 불일치에서 비롯됩니다.

  • 이러한 복잡성은 _ 제거 _되어야합니다.

  • 이전 버전과의 호환성 문제로 인해 이것이 옵션이 아닌 경우 이러한 복잡성을 _ 알려진 문제로 문서화해야합니다 _.

  • 스크립트 모듈 변수 범위 지정 동작 ( $_ 의 컨텍스트에서 참조)은 단순한 기이 한 것이 아닙니다. 이전에 언급 한 # 4568과 같은 주요 문제의 근본 원인입니다.

  • 당신이 언급 한 다른 모든 문제들은 명백한 (문서화 된) 근거 나 이익이없는 불일치로 존재하기 때문에 (주의 깊은 디자인의 결과가 아니라) 외적인 범주에 속한다고 생각합니다.

    • $null 로 splatting하여 위치 $null 인수보다 _no_ 인수를 전달하는 것이 더 합리적입니다.
    • 왜 것 [System.Management.Automation.Internal.AutomationNull]::Value 로 변환 할 수 $null 유형이 _direct 변수 assignment_에 보존되어 있어도, _parameter의 binding_ 동안? https://github.com/PowerShell/PowerShell/issues/9150#issuecomment -473743805를 참조
    • 둘러싸는 루프가없는 경우 _quiet 종료 _를 사용하여 호출 스택 전체에서 break 및 continue 의 _dynamic_ 범위 지정에 어떤 이점이 있습니까?

풍부한 기능과 서로 다른 세계의 결합만으로는 필요한 모든 _ 내재적 _ 복잡성을 기억하기 어렵지만 _ 외 재적 _ 복잡성을 최소화하는 것이 여전히 중요합니다.

의도 한 접근 방식이 효과가 있다는 것을 알고 신뢰하지 않고 먼저 테스트해야하는 경우 (또는 놀라운 동작으로 인해 예기치 않은 문제가 발생하는 경우)는 심각한 생산성 (및 즐거움) 장애입니다 (PowerShell을 사용하면 대화 형 방식으로 동작을 테스트하는 것이 매우 쉽습니다. ).

확실한 개념 (직관적 인 기대에 어긋나지 않는), 설명적인 이름 지정 및 좋은 문서로 귀결됩니다.

잘 모르거나 올바르게 기억하고 있는지 확실하지 않은 경우 어디에서 찾아야하는지 알고 있어야하며 _ 알려진 문제 및 엣지 사례 _도 문서화되어 있다는 믿음이 있어야합니다 (일반 도움말 항목의 일부로 또는 링크를 통해 그곳에).

따라서 _ 외적 복잡성 제거가 선택 사항이 아니라고 결정하더라도 최소한 _ 체계적으로 문서화 할 수 있습니다.-여기서 논의는 "함정 갤러리"를 컴파일하는 출발점이 될 수 있습니다 (피할 수없는 _ 내재적 복잡성의 경우도 포함될 수 있음). 놀라 울 수 있습니다).

우리는 적어도 체계적으로 문서화 할 수 있습니다. 여기서 논의는 "함정 갤러리"를 컴파일하기위한 시작점이 될 수 있습니다.

Roman Kuzmin은 https://github.com/nightroman/PowerShellTraps 에서 한동안 그러한 갤러리를 수집하고 있습니다.

감사합니다, @HumanEquivalentUnit- 훌륭한 컬렉션처럼 보입니다.

이 스레드에서 수집 된 문제와 함께 _official_ 문서의 일부인 갤러리의 기초를 형성 할 수 있으며, 각 항목을 적절하게 보강 할 수 있습니다.

• 예상치 못한 행동 일지 모르지만 결국 그 행동이 정당화되는 이유를 설명하는 설계 근거 (적절하게 구성된 설명으로 인해 놀라움의 요소가 사라질 수 있음)

• 다음과 같은 문제에 대한 인정

  • 둘 중 하나 : 이전 버전과의 호환성을 위해 수정되지 않습니다.
  • 또는 : 미래의 변화가 고려되고 있음
  • 또는 : PS _Core_에서 문제가 이미 수정되었습니다.

_ "PowerShell vZeroTechnicalDebt"시간이되었는지 물어봐야하는 것이 이상합니다 ._

이를 위해 필요한 버전 명령이 있습니다.

새 버전에서 무언가가 깨지면 우리가 얻는 유일한 고통은 일반적으로 작은 차이점을 연구하고 배워야한다는 것입니다.

그러나 우리는 (마지막으로) 플랫폼을 얻습니다. 이는 코어에서 반복 할 때마다 실제로 더 좋아집니다. 유지 관리가 훨씬 쉽습니다.

아니요, 새로운 노하우와 기술로 잘못된 설계와 결정을 시작하는 것은 결코 문제가되지 않습니다.

또한 죽은 말에서 살아있는 s ** t를 제거하기 위해 호스트의 기본 파일 시스템과 파일 시스템 공급자 사이의 마법적인 차이점을 처리하는 잘 작동하는 함수 또는 cmdlet을 작성하는 것은 여전히 ​​굉장합니다. 이러한 미묘한 코드는 작성하기 어렵고 종종 잘못되었습니다. 여기에 내가 7 ~ 8 년 전에 대답 한 stackoverflow에 대한 게시물이 여전히 유효합니다.

https://stackoverflow.com/questions/8505294/how-do-i-deal-with-paths-when-writing-a-powershell-cmdlet

참고 : # 8495

수정해야 할 이상한 연산자 우선 순위 규칙이 있습니다.

PS> 1, 2, 2 + 1, 4, 4 + 1
1
2
2
1
4
4
1

대부분의 언어에서 다음과 같은 결과가 더 일반적으로 예상됩니다.

1
2
3
4
5

고유 한 장점과 단점이있는 한 가지 옵션은 모든 "이상적인"동작을 활성화하여 선택하도록하는 새로운 기능 플래그입니다. 대부분의 사용량이 새로운 동작으로 이동했음을 나타내는 원격 분석이있는 경우이를 뒤집어서 옵트 아웃 할 수 있습니다. 그런 모델이 작동하는 실제 사례를 본 적이 없기 때문에 이것은 모두 파이프 꿈일 수 있습니다 ...

실제로 그것은 _nice_ 일 것입니다. 그러나이 쓰레드에있는 이러한 개정들 중 일부의 완전한 _splitting_ 특성을 감안할 때 잠재적으로 "normal"과 "experimental"사이의 스크립트의 호환성을 잠재적으로 여러 조각으로 _splitting_ 할 위험이 있습니다. 개인이 활성화 한 플래그에 따라 다릅니다.

이것은 우리가 문서 페이지에 큰 경고를 붙이거나 잠재적으로 특정 플래그가 없으면 가져 오기를 방지하지 않는 한, 그런 방식으로 실험적인 기능에 의존하거나 의존하는 스크립트와 모듈을 작성할 수 없음을 의미합니다. 활성화됩니다.

그러나 이것은 피할 수 있습니다. 그러나 우리가 마음대로 할 수 있다면 각 모듈 범위에 따라 특정 실험 기능을 활성화 및 비활성화 할 수 있습니다. 그러나 그것이 문제를 더 복잡하게 할 뿐이라는 점을 감안할 때, 그것이 특히 훌륭한 솔루션인지 확실하지 않습니다.

@ vexx32 는 명확하게 experimental 플래그를 제안하지 않았습니다. 나는 뭔가 다른 것을 생각하고 있었다 (공식적으로 지원 될 것이므로 아마도 Enable-PSFeature 와 비슷할 것이다 (따라서 실험적 기능과는 다른 변경 사항으로부터 보호됨)). 나는 또한 당신이 이러한 새로운 주요 변경 사항을 개별적으로가 아닌 세트로 선택하는 단일 플래그라고 생각했습니다.

아, 그렇다면 ... 네, 물론입니다. 그것은 우리가 하나의 우산 아래에 모든 것을 깔끔하게 포장하고 실제로 사용할 수있게 해줍니다. 내가 생각했던 것보다 훨씬 낫다! 😄

# 8512를 기반으로 여기에 컴파일 된 문제 목록에 @ jszabo98 추가 :

-and 및 -or 예기치 않게 _same_ 우선 순위를 갖는 반면, 대부분의 언어 (C # 포함)에서 -and 는 -or 보다 우선 순위가 높습니다.

기대에 어긋나는 표현의 예 :

PS> $true -or $true -and $false
False

left-associativity와 -and 및 -or 의 우선 순위가 동일하기 때문에 위는 예상되는 $true -or ($true -and $false) 아닌 ($true -or $true) -and $false 로 평가됩니다.

그런 모델이 작동하는 실제 사례를 본 적이 없기 때문에 이것은 모두 파이프 꿈일 수 있습니다 ...

사실, 우리는 이미 전 세계에서 작동하는 모델 인 LTS를 가지고 있습니다. MSFT는이를 사용하여 Windows 10을 개발합니다.이 모델은 Unix 배포판을 개발하는 데 사용됩니다.
우리에게 이것은 2 년마다 LTS PowerShell Core 버전을 릴리스하고 Windows 10 LTS 버전과 Unix LTS 버전에 포함 할 수 있음을 의미합니다. (한 가지 문제는 LTS 버전의 Windows 및 Unix 릴리스 날짜를 동기화하는 것입니다. MSFT는 주요 Unix 회사와 협상 할 수 있다고 생각합니다.)
이 2 년 동안 우리는 사소한 주요 변경 사항을 수집하여 더 중요한 주요 변경 사항을 다음 주기로 이전합니다.
각각의 새 LTS 버전에 대해 ScriptAnalyzer는 스크립트 마이그레이션을 용이하게하기 위해 일련의 새 규칙을 가져와야합니다.
이 모델을 사용하면 중요한 제품과 스크립트는 철저한 테스트와 마이그레이션 후에 이전 버전에서 다음 버전으로 이동하기 만하면됩니다.

지원되는 PHP 5.x 버전에 도달 할 때까지 이전 시스템을 PHP 4 버전에서 다음 PHP 버전으로 단계별 (버전 별) 마이그레이션 할 때이 접근 방식을 사용했습니다. 각 단계에서 나는 비교적 작고 빠른 변경을해야했고 그 후 시스템은 다음 단계까지 얼마 동안 계속 작동했습니다.

업데이트 : .Net Core LTS 버전과 동기화되어야합니다. .Net Core 3.1이 다음 LTS가 될 것이며 PowerShell Core 6.x가 버전에 있어야 할 것으로 예상합니다.

솔직히? PowerShell Core에 대한 정말 _great_ 아이디어처럼 들립니다. 이렇게하면 LTS 릴리스 사이의 중간에 너무 많은 주요 변경 사항으로 인해 과도한 부담을주지 않고 앞으로 나아가는 데 도움이 될 수있는 이와 같은 주요 변경 사항을 만들 수 있습니다.

참고 : https://github.com/PowerShell/PowerShell/pull/8407#issuecomment -453221566

Get-Variable -ValueOnly -Name myVar | Should -Be $var $var 가 배열 Get-Variable -ValueOnly -Name myVar | Should -Be $var 어설 션이 실패합니다.

이는 Get-Variable -ValueOnly 이 WriteObject() 대해 열거 오버로드를 사용하지 않기 때문입니다.

기능 세트가 다르고 주요 변경 사항이있는 여러 버전의 powershell이있는 경우 : 이미 레거시 및 코어가 포함되어 있습니다. 언뜻보기에는 좋지 않은 것 같지만 미래를위한 작업 모델을 제공 할 수 있습니다. 나와 함께있어 ...

Windows 예약 작업, 젠킨스 및 많은 환경이 powershell 코어를 인식하지 않기 때문에 실제 스크립트를 실행하기 전에 powershell을 사용하여 코어 pwsh.exe를 호출하는 거의 모든 프로세스를 설정해야합니다. 특정 PS 버전에서만 사용할 수있는 기능을 사용하기 때문입니다.

코어를 강제로 호출 할 수없는 경우 모든 스크립트가 실행중인 PS 버전을 확인한 다음 호스트 시스템에서 적절한 PS 버전을 사용하여 자체 호출해야합니다. 올바른 코드를 올바른 환경에서 실행하기 위해 사용하는 트릭이 무엇이든간에 우리는 종종 모든 환경과 매개 변수를 이미 실행중인 동일한 스크립트에 전달합니다.

이것이 유닉스 철학입니다. 도구가 한 가지 일을하고 잘 수행하도록하십시오. 그런 다음 도구를 결합하여 부분의 합보다 큰 전체를 만듭니다. 이것은 우리가 항상 다른 유틸리티에 서브 쉘을 호출하고 결과를 처리하는 스크립팅의 세계입니다. 역사적으로 그것은 스크립팅입니다. Powershell은 모든 코드를 네이티브로 유지하려고 시도하여 이상한 규칙으로 경향이 있지만 이는 요구 사항이 아닌 규칙 일뿐입니다. PS는 유닉스 쉘 스크립트와 마찬가지로 OS 및 모든 유틸리티에 액세스하여 실행됩니다.

core의 파일 확장자가 .ps6으로 업데이트되어 powershell 엔진이 우리를 위해 작업을 수행 할 수 있다면 훨씬 쉬울 것입니다. powershell의 각 바이너리 버전은 하나에 대한 모든 호출이 환경을 통과하고 출력, 오류, 경고, 예외를 다른쪽에 반환하는 한 다른 버전과 독립적으로 유지 될 수 있습니다. 엔진이 실행할 버전을 알고있는 한 엔진에서 이전 버전과 호환되는 플래그를 가질 필요는 없습니다. 관련된 컨텍스트 전환이 이미 일어나고 있으므로 이미 최악의 시나리오에 있습니다.

잘 정의 된 방식으로 작업을 중단하지 않는 한 우리는 powershell에서 끔찍한 해킹을 영원히 사용해야 할 것입니다. 획기적인 변화가 우리의 삶을 지금보다 더 어렵게 만들지는 않을 것입니다. 또는 점진적이고 지속적인 개선을 사용하고 엔진이 컨텍스트를 전환하는 무거운 작업을 수행하도록하면 코드 (및 수명)가 더 좋아질 것입니다.

@ jtmoree-kahalamgmt-com 피드백 주셔서 감사합니다! 새로운 문제를 자유롭게 열어 경험과 피드백을 공유하고 새로운 유용한 기능을 요청하십시오.

core의 파일 확장자가 .ps6으로 업데이트되어 powershell 엔진이 우리를 위해 작업을 수행 할 수 있다면 훨씬 쉬울 것입니다.

https://github.com/PowerShell/PowerShell/issues/2013#issuecomment -247987977 참조

그리고 귀하의 의견을 바탕으로 https://github.com/PowerShell/PowerShell/issues/9138을 만들었습니다.

Python 3은 확실히 공포의 쇼입니다. 아직 실제로 사용 되었습니까? 아직 2.7을 실행 중이며 곧 업그레이드 할 계획은 없습니다. 하지만 최근에도 Perl 6에 대해 많이 듣지 못했습니다 ...

파이썬에서 배울 수있는 교훈은 엔진의 버전 변경에서 언어의 주요 변경 사항을 분리하는 것입니다. 가설 적으로 PS 7 엔진은 중단없는 변경 모드에서 이전 스크립트 (.PS1) 파일을 계속 실행할 수있는 반면, 스크립트가 7 인식 (예 : .PS7 확장자)으로 표시되면 업데이트되었다고 선언 할 수 있습니다. 실행하려면 최소한 PS 7이 필요합니다. 이해가 되길 바랍니다.

저는 파이썬 3를 공포 쇼라고 부르는 것이 지나치게 극적이라고 생각합니다. PyPi 에서 오면 v3가 이제 거의 모든 상위 패키지에 대해 33 %의 침투율을 깨고 Ken Reitz의 요청 라이브러리와 같은 최신 라이브러리의 경우 거의 50/50 분할 : 어제 v3의 685k 다운로드, v2의 875k 다운로드가있었습니다.

Python 3를 오랫동안 방해하는 주요 요인은 pandas와 pysci에 대한 과학 커뮤니티 지원이었습니다. 그러나 최신 통계에서 과학 커뮤니티는 이제 Python 3을 Python 2보다 선호합니다. https://pypistats.org/packages/pandas 231k v3 다운로드, 175k v2 다운로드.

유명한 W. Edwards Deming 박사는 "하나님을 신뢰하고 다른 모든 사람들은 데이터를 가져 오십시오!"라고 말했습니다. PyPi 데이터 세트를 분석하고 Python 3가 데이터를 사용하는 방법을 알려주는 PowerShell 스크립트를 작성할 수 있습니다. https://packaging.python.org/guides/analyzing-pypi-package-downloads/

나는 (정확한 순서로) 만족할 것입니다.

1. 좋은 스택 추적을 생성하는 모듈 시스템을 사용하기가 더 쉽습니다.

   • 예를 들어, psm1 파일을 사용하면 함수가로드되는 방식에 대한 임의의 규칙을 설명 할 수 있지만 이로 인해 모든 함수가 psm1 파일에 논리적으로 globbed되는 비밀 스택 추적이 발생합니다. 이것은 스택 트레이스의 줄 번호가 초콜릿 주전자만큼 유용하다는 것을 의미합니다.

2. 스택 기반 폰 노이만 아키텍처에서 프로그래밍의 유용성을 99 % 삼키는 PowerShell 기본 오류 개체 문자열 형식을 대체합니다.

   • C #은 어느 정도이 권리를 얻습니다. PowerShell은 너무 영리합니다.

3. 출력 스트림을 null 장치로 리디렉션하는 세 가지 다른 방법이 성능면에서 동일하도록 null 리디렉션을 수정합니다.

4. 동적 범위 지정 수정 :

function a($f) {& $f}
function main() {
    $f = {write-host 'success'}
    a {& $f} # stack-overflow
    a {& $f}.getnewclosure() # okay
}
[void] (main)

1. 변수 캡처 수정 :

set-strictmode -version 'latest'
$erroractionpreference = 'stop'

function main() {
    $a = 'foo'
    $f = {
        $g = {$a}.getnewclosure()
        & $g # "variable '$a' cannot be retrieved because it has not been set."
    }.getnewclosure()
    & $f
}

main

1. 출력이 누적됩니다. return 는 다른 언어와 동일한 기능을 수행하지 않습니다. 고쳐주세요.

2. PowerShell에는 개체의 외부 리소스 처리를위한 구문 설탕이 없습니다.

3. PowerShellGet을 다시 작성하십시오. 그것은 끔찍합니다. 수백 줄의 코드, 삼켜 진 예외, 테스트 커버리지가없는 함수.

4. 모듈 캐싱이 작동하는 방식을 제거하십시오.

   • 캐시는 스레드로부터 안전하지 않습니다. WTF?
   • 분석 목적으로 모듈을 캐싱하는 전체 개념은 kludge / hack입니다. PowerShell이 ​​너무 느리기 때문에 Microsoft 내에서이 기능에 대한 큰 지원이 있다는 것을 알고 있지만 진정한 수정에 대한 다음 제안을 참조하십시오.
   • AnalysisCache 를
   • 분석을위한 모듈 캐싱은 분석을 모듈의 런타임 상태와 밀접하게 연결합니다.

5. 성능 향상을 위해 Py 파일이 pyc 파일로 컴파일되는 방식과 유사한 "컴파일 된 모듈"을 제공합니다.

6. $none 리터럴 추가

   • 여러 곳에서 $null 를 $none 로 바꾸는 것이 좋습니다.
   • ParameterSetName의 작동 방식을 재고하고 $none 특수 값을 매개 변수에 전달할 수 있도록하여 코드를 5 가지 다른 방식으로 호출하기 위해 미친 switch 문을 작성할 필요가 없도록합니다. COM 및 C # dynamic은이를 올바르게 수행합니다. PowerShell은이를 재앙으로 만듭니다. 예를 들어 구독 발생 유형에 따라 ReportingServicesTools 모듈에서 SSRS 보고서에 대한 배포 구성을 동적으로 매핑하는 방법이 있습니다. 나는 최종 사용자에게 외부 적으로 복잡성을 강요하는 것보다 속성 가방을 전달하고 그 방법이 내부적으로 복잡성을 처리하도록하는 것을 선호합니다. ParameterSetName은 프로그래밍에 좋지 않은 템플릿으로서의 개념으로 만 유용합니다. 그것은 intellisense와 ad-hoc polymorphism을 혼동합니다.

@jzabroski ErrorRecord이 서식에 대해서는, 그 논의하기 위해 사용되는 별도의 문제가있다 : https://github.com/PowerShell/PowerShell/issues/3647를 포맷하면 주요 변경으로 간주되지 않기 때문에, 우리는 개선이 할 수 있습니다.

다른 요청 중 일부는 잠재적으로 추가적이며 중단되지 않으므로 별도의 문제 여야합니다. 이 특정 문제는 기회가 있고 PS의 새로운 주요 버전을 수행하는 것을 정당화 할 수있는 경우 주요 변경 사항에 대한 요청을 논의하고 있습니다.

@jzabroski ErrorRecord 형식화와 관련하여 논의하는 데 사용되는 별도의 문제가 있습니다. # 3647 형식화는 주요 변경 사항으로 간주되지 않으므로 개선 할 수 있습니다.

_Why_ 이것이 브레이킹 체인지가 아닌가? 개발자가 처음에 오류 메시지의 문자열에 대해 패턴 일치를해서는 안 되나요? 나는 그것이 타당하다고 생각합니다. 그러나 여전히 하위 소비자를 깰 것입니다.

다른 요청 중 일부는 잠재적으로 추가적이며 중단되지 않으므로 별도의 문제 여야합니다.

어떤 것이 잠재적으로 가산 적이라고 생각합니까? 이 토론을 방해하지 않도록 문제를 만들 수 있지만 오늘 아침이 목록을 신중하게 작성했습니다. 나는 천둥을 울리고 번개를 터뜨리는 분노와 열정을 가진 PowerShell을 싫어 합니다. PowerShell은 정육점 칼이 달린 볼링 공입니다. 엔지니어로서 가장 당황했던 5 가지 순간은 모두 PowerShell을 사용하는 동안 발생했습니다. 나는 그 시간을 결코 되찾지 못할 것이다.

나는 왜 이것이 깨지는 (그리고 멋진) 변경 제안인지 명확히하기 위해 내 제안을 업데이트했습니다.

출력이 누적됩니다. return은 다른 언어와 같은 일을하지 않습니다. 고쳐주세요.

return 는 class 메서드 내에서 예상대로 작동합니다. 일반 / 고급 PS 기능에서 "출력이 축적"되는 방식은 Korn 쉘 및 Bash와 같은 쉘 스크립팅 환경에서 매우 일반적입니다. 즉, 콘솔에서 여러 명령을 복사하여 함수에 넣습니다. 해당 함수를 호출하면 콘솔에서 해당 명령을 실행할 때와 마찬가지로 각 명령에서 출력됩니다.

PowerShell에 대한 나의 주요 불만은 일반 / 고급 함수의 경우 return 가 인수를 가져 오지 않아야한다는 것입니다. 다음과 같기 때문입니다.

return $foo

실제로 다음과 같이 실행됩니다.

$foo
return

이것은 사람들에게 return을 사용하여 출력을 제어 할 수 있다는 느낌을줍니다.

return 는 class 메서드 내에서 예상대로 작동합니다. 일반 / 고급 PS 기능에서 "출력이 축적"되는 방식은 Korn 쉘 및 Bash와 같은 쉘 스크립팅 환경에서 매우 일반적입니다.

나는 사람들이 @BrucePay를 포함하여 습니다 (아래 강조 , 그를 인용), 결론은 다음과 같습니다.

• Korn Shell에서 return은 함수 마침표를
• Bash에서 return은 함수 마침표를

PowerShell에서만이 비논리적 "반환이 반환되지 않음"넌센스가 있고 출력이 누적됩니다. 이것은 영광스러운 메모리 누수이며 그렇게 생각해야합니다.

솔직히 말해서 PowerShell In Action의 모든 곳에서 "problems"라는 문구를 검색하면 vZeroTechnicalDebt 목록에 무언가를 추가 할 수 있습니다. 다음은 Bruce가 return 문에 대해 쓴 내용입니다.

7.3 함수에서 반환 값
이제 함수에서 값을 반환하는 것에 대해 이야기 할 때입니다. 우리는이 작업을 계속 해왔지만 강조해야 할 것이 있습니다. PowerShell은 셸이기 때문에 결과를 반환하지 않고 출력을 작성하거나 개체를 내 보냅니다. 보시다시피 표현식 또는 파이프 라인의 결과는 결과 개체를 호출자에게 내보내는 것입니다. 명령 줄에서 세미콜론으로 구분 된 세 개의 식을 입력하면 세 명령문의 결과가 모두 출력됩니다.
[...]
기존 접근 방식에서는 생성되는 배열을 유지하기 위해 결과 변수 $result 를 초기화하고 각 요소를 배열에 추가 한 다음 배열을 내 보내야합니다.

PS (16) > function tradnum
> {
> $result = @()
> $i=1
> while ($i -le 10)
> {
> $result += $i
> $i++
> }
> $result
> }

이 코드는 훨씬 더 복잡합니다. 이제 함수에서 하나가 아닌 두 개의 변수를 관리해야합니다. 배열 크기를 자동으로 확장하지 않는 언어로 작성했다면 배열 크기를 수동으로 조정하려면 코드를 추가해야하므로 훨씬 더 복잡 할 것입니다. PowerShell이 ​​배열의 크기를 자동으로 조정하더라도 스트리밍 된 출력을 캡처하는 것과 비교할 때 비효율적입니다. 요점은 PowerShell이 ​​제공하는 기능을 사용하여 개선 할 수있는 방법에 대해 생각하게하는 것입니다.
귀하의 코드. 배열을 명시 적으로 구성하는 코드를 작성하는 경우 대신 스트리밍을 활용하기 위해 다시 작성할 수 있는지 살펴 보는 것이 좋습니다.

이 기능의 동기는 좋은 것 같지만 동일한 목표를 달성하기위한 훨씬 깔끔하고 읽기 쉬운 방법이 있습니다. 단일 개체에서 개체 컬렉션으로의 암시 적 승격입니다. 또한 PowerShell에는 이미 리디렉션에 대한 출력을 반환하는 간단한 방법이 있습니다 : Write-Output .

Bash에서 return은 함수, 마침표를 종료합니다.

어? Bash는 다음과 같이 출력을 누적합니다.

hillr@Keith-Dell8500:~$ function foo() {
> echo "Hello"
> ls ~
> date
> return
> echo "World"
> }
hillr@Keith-Dell8500:~$ foo
Hello
bar.ps1  date.txt   test.ps1
baz.ps1  dotnet    powershell-preview_6.2.0-rc.1-1.ubuntu.16.04_amd64.deb
Tue Mar 26 16:06:18 DST 2019

PowerShell과 마찬가지로 Bash는 return 문까지 각 명령의 모든 것을 출력합니다.

아, $? 에서 반환 된 내용을 참조하는 것 같습니다. 네, 차이입니다. 성공 / 실패를 나타 내기 위해 Bash에서 int 반환 값이어야한다고 생각합니다. PS에서 $? 는 함수에서 생성 된 오류를 기반으로 성공 / 실패를 bool로 나타냅니다. 실제로 $? 는 그렇게 많이 사용되지 않는다고 생각합니다. 대신 try/catch/finally 를 통해 예외 처리를 사용합니다.

예. return 은 (는) 해당 언어에서 하나의 목적 만 가지고 있습니다. PowerShell에서는 출력과 혼합됩니다. 반환 값과 출력 스트림을 혼합하는 것은 좋지 않습니다. 또한 메모리 누수와 같은 성능 문제로 이어질 수 있습니다. 정말로 원하는 것은 공동 루틴 또는 "수익률 반환"또는 생성기, 생성기 생성자 및 스캐너 (아이콘에서와 같이)입니다. 그 이유는 입력 소비가 게으르고 실패로 인해 지금까지 생성 된 계산 부분이 처리 될 수 있도록 허용하면서 계산이 일시 중단되기 때문입니다.

"출력 리디렉션"은 실제로 두 개의 개체, 즉 Processor와 ProcessorContext로 생각할 수 있습니다.

편집 : 나는 당신이 내 원래의 요점을 반박 한 이유를 봅니다. 당신은 내가 산출물을 산출 할 수있는 것이 나쁘다고 말하고 있다고 생각했습니다. 대신 PowerShell이 ​​수행하는 방식으로 출력을 반환하는 것이 좋지 않습니다.

대신 try/catch/finally 를 통해 예외 처리를 사용합니다.

그것은 많은 타이핑이며 모든 경우에 의도를 명확하게 표현하지 않습니다.

음, PowerShell은 가비지 수집되는 .NET을 기반으로하므로 메모리 "누수"를 겪지 않아야합니다. 그렇다고해서 기억력을 쌓을 수 없다는 뜻은 아닙니다. 따라서 변수에 할당되거나 일종의 해시 테이블에 배치 된 큰 출력 / 컬렉션을 처리 할 때 약간주의해야합니다.

PowerShell의 return 문은 단 하나의 목적 만 가져야하며 다른 것은 아무것도없이 일찍 반환하는 것입니다. 누군가 return 42 하면 $? 와는 아무런 관련이 없습니다. 출력 스트림에 대한 또 다른 항목 출력 (양보)입니다.

앞서 언급했듯이 $? 는 PowerShell에서 관리하며 함수가 출력 / 반환하는 것과 관련이 없습니다. $? 는 생성 된 오류 (또는 그 부족)에 따라 설정됩니다. 즉, $res = foo -$ res를 실행하면 foo 함수가 출력하는 모든 객체가 포함됩니다. 함수가 "실패"했는지 알고 싶다면 실행하는 모든 명령에 대해 $? 를 검사하거나 try/catch 블록에 여러 명령을 래핑 할 수 있습니다. 나는 이전의 타이핑이 훨씬 적다는 것을 알았다 (스크립트에서).

@BrucePay를 포함하여 사람들이 이것을 말하는 것을
Korn Shell에서 return은 함수, 마침표를 종료합니다.
Bash에서 return은 함수, 마침표를 종료합니다.

PowerShell에서 return은 함수도 종료합니다.

PS C:\> function test { "hello"; return "!"; "world"}
PS C:\> test
hello
!

반환 값과 출력 스트림을 혼합하는 것은 좋지 않습니다. 또한 메모리 누수와 같은 성능 문제로 이어질 수 있습니다.

출력 스트림과 PowerShell의 반환 값간에 차이가 없기 때문에 혼합이 없습니다. 함수가 문자열을 stdout에 쓰고 별도로 느낌표를 호출자에게 반환하는 것처럼 말하고 있지만 그렇지 않습니다. write-output 가리키는 것도 같은 실수 인 것 같습니다. 이 모든 것 : write-output 'x' , 'x' , return 'x' 같은 출력 경로에서 파이프 라인으로 무언가를 보냅니다. 별도의 반환 값이 없습니다.

정말로 원하는 것은 공동 루틴 또는 "수익률 반환"또는 생성기, 생성기 생성자 및 스캐너 (아이콘에서와 같이)입니다. 티

즉, 명령 줄에 명령을 작성한 다음 스크립트 나 함수에 넣으면 다르게 동작합니다.

PS C:\> robocopy /whatever
PS C:\> "robocopy /whatever" | set-content test.ps1; .\test.ps1
PS C:\> function test { robocopy /whatever }

나는 아무 이유없이 yield return 를하지 않았기 때문에 두 경우에 출력을 삼키지 않는 세 가지 경우 모두에서 동일한 출력을 보는 것을 좋아합니다. PowerShell이 ​​수행하는 방식은 셸 및 셸 / 배치 스크립트 작성에 일관되고 편리합니다. 명령 줄에 작성한 내용을 가져 와서 계속 호출 할 수있는 곳에 배치합니다. 그렇게한다고해서 코드 동작 방식이 완전히 바뀌지는 않습니다.

그 이유는 입력 소비가 게으르고 실패로 인해 지금까지 생성 된 계산 부분이 처리 될 수 있도록 허용하면서 계산이 일시 중단되기 때문입니다.

PowerShell 파이프 라인은 런타임에 의해 제어됩니다. 말씀하신 내용을 이해한다면 이미 수행 할 수 있습니다.

PS D:\> 1..1mb |foreach { write-verbose -Verbose "incoming number: $_"; $_ } |select -first 3
VERBOSE: incoming number: 1
1
VERBOSE: incoming number: 2
2
VERBOSE: incoming number: 3
3

select 는 세 가지가있는 즉시 파이프 라인을 종료합니다. 나머지 백만 개의 숫자는 foreach 입력되지 않았습니다. 파이프 라인 아래로 이동하는 정보는 "푸시"모델이지만 PowerShell 엔진에 의해 제어됩니다.

셸이기 때문에 입력이 기본 명령이나 PS cmdlet 외부의 항목에서 오는 경우 "계산을 일시 중단하기위한 입력 실패"의 의미는 명확하지 않습니다.

성능 향상을 위해 Py 파일이 pyc 파일로 컴파일되는 방식과 유사한 "컴파일 된 모듈"을 제공합니다.

성능 향상을위한 의도 된 솔루션은 C #으로 모듈을 작성하는 것입니다. PowerShell 코드는 경우에 따라 JIT를 컴파일하지만 PS 팀 구성원은이를 사용자 지정을 위해 최종 사용자에게 공개 할 계획이 없다고 말했습니다. 예를 들어 IIRC Dongbo Wang의 PS Conf Asia가 2018 년 11 월

출력 스트림을 null 장치로 리디렉션하는 세 가지 다른 방법이 성능면에서 동일하도록 null 리디렉션을 수정합니다.

바람직하지만 그럴 것 같지 않습니다. $null = 4 는 간단한 변수 바인딩이고, 4 | out-null 는 파이프 라인을 시작하고 명령 해결을 수행하는 오버 헤드가 필요합니다. 누군가 의도적으로 out-null 로깅을 추가 한 프록시 래퍼로 만든 경우 암호? 파이프 라인 및 cmdlet 실행을 요청하는 것이 식보다 느린 기술 부채입니까?

동적 범위 수정 :

"동적 범위 지정 사용 안 함"을 의미하는 경우 의도적 인 선택이었습니다. 예를 들어 Bruce Payette에서 "동적 범위 지정, 이것은 거의 사용되지 않습니다. 이전에는 30 년 전처럼 LISP에 동적 범위 지정이 있었지만 거의 사용되지 않습니다. 지금 우리가 사용하는 이유는 쉘이 사용하는 이유입니다. 쉘은 동적 범위 지정 (Bash까지)과 동등한 것을 사용하고 Unix 쉘은 동적 범위 지정과 동등한 것을 사용합니다. 여기서 호출자의 컨텍스트의 변수는 호출자 컨텍스트의 변수가 자식 컨텍스트에 복사됩니다. [..] 일반적으로 동적 범위 지정에서 한 번의 수정으로 호출 체인을 조회하고 존재하는 위치에 변수를 설정합니다. 그렇게하지 않고 변수를 설정합니다. 항상 현재 범위에서, 그리고 다시 쉘의 동작을 에뮬레이트합니다. "

그것은 성 가실 수 있지만, 쉘에 대한 "기술 부채"이며 변경되면 "zeroTechnicalDebt"가 될까요?

음, PowerShell은 가비지 수집되는 .NET을 기반으로하므로 메모리 "누수"를 겪지 않아야합니다. 그렇다고해서 기억력을 쌓을 수 없다는 뜻은 아닙니다. 따라서 변수에 할당되거나 일종의 해시 테이블에 배치 된 큰 출력 / 컬렉션을 처리 할 때 약간주의해야합니다.

엔지니어가 아닌 시스템 관리자가 8TB 파일 공유의 모든 파일에 대한 메타 데이터를 표로 만드는 논리를 작성했습니다. 그것은 잘 끝나지 않았습니다 : 그것은 많은 메모리를 소모했고 또한 시스템을 100 % cpu로 고정 시켰습니다 ... 스크립트가 시작된 후 우리는 심지어 상자에 로그인조차 할 수 없었고, 서버를 저장하는 유일한 해결책은 _ 생산 중 _입니다. 하드 재부팅했습니다.

내 경험상 PowerShell을 사용하면 이러한 쓰레기를 쉽게 작성할 수 있습니다. 내 피드백을 원하는대로 할 수 있고 비평 할 수 있습니다. PowerShell을 사용하면 프로덕션 컴퓨터를 효과적으로 충돌시킬 수있는 스크립트를 쉽게 작성할 수 있다는 사실은 변하지 않습니다.

@jzabroski 스크립트의 세부 사항을 공유 할 수 있습니까?

Powershell 사람들은 메모리 사용을 줄이기 위해 의도적으로 데이터 세트 ( $files = get-childitem; $files | foreach-object )를 미리로드하는 대신 파이프 라인 스트리밍 ( get-childitem | foreach-object {} )을 권장합니다. 선불 로딩을 했나요?

유사한 파일을 수집하기 위해 Group-Object 를 사용 했습니까? 최근에 메모리 사용이 아닌 경우 CPU 사용을 줄이는 그룹 개체 성능이 향상되었습니다 .

PowerShell은 기본적으로 단일 코어이며 작업 / 실행 공간 코드가 있었습니까? 단일 코어 서버였습니까? PS 6.1에는 CPU 사용을 제어하는 ​​데 도움이되는 오버 헤드와 스로틀 링이 훨씬 적은 여러 작업을 허용하는 Start-ThreadJob 이 있습니다.

내 경험상 PowerShell을 사용하면 이러한 쓰레기를 쉽게 작성할 수 있습니다.

$files = @(); $files += $f 를 쓰라고하는 모든 튜토리얼과 책은 CPU주기와 메모리에있어 세상에 약간의 비용이 들었을 것입니다. 이는 느리고 프로세서와 메모리 비용이 많이 들고 매우 일반적인 패턴입니다. 그 패턴이 대본에 전혀 포함되어 있는지 궁금합니다. (그리고 만약 우리가 이전 버전과의 호환성을 깨지 않고 그것을 막을 수있는 방법이 있다면, 또는 미래의 주요 변경에서 배열에서 + =를 무효화 할 수 있습니까?).

그러나 여기에는 절충점이 있습니다. Get-ChildItem -Recurse 는 22 자이고 내 C : 드라이브에서만 800MB 이상의 RAM을 사용합니다. 많은 메모리를 사용하지 않고이를 수행하는 C # 은 50 줄 이상이며 파일 메타 데이터를 전혀 얻지 못합니다. 80MB에 가깝습니다. 그것은 PS 누수 메모리가 아니라 사용자 편의를 위해 PS를 사용하는 것입니다.

작동 방식에 대한 세부 사항에 신경 쓸 필요가없고, 유용한 코드를 작성할 수 있고, 나쁜 코드를 작성할 수없고, 숙련 된 프로그래머가 아니어도되는 언어가 있습니까? (그리고 어느 것도 껍데기입니까?)

이전에 제안한 변경 사항이 스크립트가 작동하도록 만들었습니까?

Bash 스크립트를 작성하여 파일을 나열하고 각 파일에 대한 프로세스를 생성 할 수 있습니다. 서버가 무너지고 SSH를 수행 할 수도 없습니다. os.walk() 파일 트리를 os.stat() 하고 각 파일에 대해

나는 PS가 더 많은 "성공의 구덩이"와 더 적은 여행 위험을 가지기를 바랍니다. 빠른 파일 이름 목록은 내가 많이 사용하는 것 중 하나입니다. 완전히 다른 언어로 급격히 변경하고 잘하는 영역을 호전하는 것은 그렇게하지 않습니다.

당신은 파이썬을 원하고, 파이썬이 존재하고, 아름다운 언어이며, 두 개의 다른 세계에 맞추려고 노력하고 다른 OS (왜, 마이크로 소프트) 또는 마이크로 소프트의 약속에 의해 30 년 된 셸의 범위와 함수 반환 의미를 유지하려고해서 방해받지 않습니다. 이전 버전과의 호환성 (그리고 .Net에 대한 집착)에 대한 것이므로 이러한 모든 질문에 직면하기보다는 피해야합니다.

나는 PS가 더 많은 "성공의 구덩이"와 더 적은 여행 위험을 가지기를 바랍니다.

그것만으로도 20 개의 엄지 손가락을 추가 할 수 있다면 그렇게 할 것입니다. 이것이 바로 PowerShell이 ​​취해야하는 패턴과 접근 방식입니다.

For-EachObject는 PowerShell 컬렉션을 가져와 읽을 수없는 스택 추적으로 변환하기위한 PowerShell 함수입니다.

오늘 저는 Amazon에서 작성한 스크립트를 사용하여 EC2 Windows 디스크를 나열했습니다. https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-windows-volumes.html#windows -list-disks

뭔지 맞춰봐? 이 PC에 Initialize-AWSDefaults 설정이 없었고 스크립트 작성자가 ForEach-Object를 사용했기 때문에 스택 추적은 다음과 같이 보입니다. _garbage_ :

PS C:\Windows\system32> D:\Installs\PowerShell\List-EC2Disks.ps1
Could not access the AWS API, therefore, VolumeId is not available. 
Verify that you provided your access keys.
ForEach-Object : You cannot call a method on a null-valued expression.
At D:\Installs\PowerShell\List-EC2Disks.ps1:39 char:12
+ Get-disk | ForEach-Object {
+            ~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [ForEach-Object], RuntimeException
    + FullyQualifiedErrorId : InvokeMethodOnNull,Microsoft.PowerShell.Commands.ForEachObjectCommand

이것은 _ 사람들이 코드에서 ForEach-Object 표현식을 사용할 때마다 _ 발생합니다. 스택 추적은 _ 항상 끔찍합니다 _. 이것을 다시 쓰는 것은 고통 스럽습니다. 고맙게도 이것은 임의의 파일에 복사하여 붙여넣고 저장하고 실행하는 스크립트 일뿐입니다. 큰 모듈에서 문제가 발생하면 모듈의 소스 코드를 가져 와서 스크립트를 다시 작성하고, 리팩토링에서 신이 길 바라며, ForEach-Object 표현식을 변환하여 모듈 전체에서 어떤 것도 깨뜨리지 않았 으면합니다. REAL 오류가 어디에 있는지 알아 내서 _ 내 일을 할 수 있습니다 _. 이제 PowerShell의 Write-Error 가 throw new Exception("message", ex) 의 C # 간단한 관용구에 비해 끔찍하기 때문에 오류가 발생하는 이유를 파악하기 위해 일부 주요 저장소에서 분기 한 사용자 지정 코드가 있습니다.

용도이을 다시 - 쓰기 for ($var in $list) 변수에 결과를 축적, $results , 나는 다음과 같은 오류가 발생합니다 :

PS C:\Windows\system32> D:\Installs\PowerShell\List-EC2Disks.ps1
Could not access the AWS API, therefore, VolumeId is not available. 
Verify that you provided your access keys.
You cannot call a method on a null-valued expression.
At D:\Installs\PowerShell\List-EC2Disks.ps1:58 char:26
+ ... lDevice = If ($VirtualDeviceMap.ContainsKey($BlockDeviceName)) { $Vir ...
+                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : InvokeMethodOnNull

아, 그런데이 작업을 할 때마다 목록에 항목을 추가하는 PowerShell의 어리석은 규칙이 기억 나지 않으므로 Google https://www.google.com/search?q=powershell+append를 사용해야합니다. + 직관적이지 않은 PowerShell의 목록 작업이 어떻게 이루어지는 지 설명하는 누군가에 대한 블로그 게시물을

C # 또는이 작업을 잘 수행하는 언어를 모르는 경우이 동작이 괜찮다고 주장하기 쉽습니다. 그러나 C #은 AggregateException에서 예외를 래핑하여이 문제를 지능적으로 처리하므로 내부 및 외부 예외를 모두 얻을 수 있습니다. PowerShell? 하 하하하. 예, 너무 유용 할 것입니다.

@jzabroski 스크립트의 세부 사항을 공유 할 수 있습니까?

슬프게도 (_ 그리고 행복하게 _) 기억이 안나요. 파일 공유 였으므로 거의 확실하게 최대 1 ~ 2 개의 코어였습니다. 코어가 2 개인 경우 나머지 CPU는 Windows Defender가 차지했을 가능성이 높습니다.

편집 : Teams 채팅에서 찾았습니다.

$big32 = Get-ChildItem D:\Data\Website\Data -recurse | Sort-Object length -descending | select-object -first 32 | measure-object -property length –sum

추가 보너스로, 나는 방금이 명령을 실행 한 사람 (매우 나쁘다고 느꼈다)과 이야기를 나눴으며 그는 사용 사례가 "DFS에 대한 초기 복제 그룹 크기 조정 요구 사항에 대해 가장 큰 32 개의 파일을 가져 오는 것"이라고 말했습니다.

출력 스트림과 PowerShell의 반환 값간에 차이가 없기 때문에 혼합이 없습니다.

나는 사람들이 첫 번째 시도에서 이것을 올바르게 사용하는 것을 아직 보지 못했습니다. 다시 말하지만 이것은 bash가하는 일이나 다른 쉘이 아닙니다. 두 개념을 통합하는 것은 흥미로운 실험 이었지만 가독성 관점에서는 완전하고 완전한 재앙이었습니다. Write-Output 가 PowerShell v6에서 16 개월 동안 손상되었다는 것은 도움이되지 않습니다.

For-EachObject 출력에서 @jzabroski Powershell Core를 사용하지 않는 것 같습니다 (이 저장소가 전용). Powershell 코어를 사용해보고 재현 할 수 있는지 확인하십시오. 최신 버전을 사용하십시오. Windows 특정 기능 (예 : Get-Disk)은 Powershell Core의 일부가 아니므로 테스트를 수행하는 동안이 점을 고려해야합니다.

나는 사람들이 첫 번째 시도에서 이것을 올바르게 사용하는 것을 아직 보지 못했습니다. 다시 말하지만 이것은 bash가하는 일이나 다른 쉘이 아닙니다.

$ test () { ls /tmp; ls /etc/pm; return 5; ls /v*; } ; x=$(test)
$ echo "$x"
tmux-1000
sleep.d
$ echo $?
0

그것은 Bash 함수에 누적되는 두 개의 개별 명령의 출력 이며 Bash는 C #에서 반환 함수로 작동하지 않는 것을 반환합니다. 구체적으로 "Bash가하는 일이 아님"이란 무엇입니까?

bash 예제에 대한 반환 값을 올바르게 캡처하지 않습니다. $? 때문에 반환이 손실됩니다. 항상 마지막 명령입니다. 귀하의 경우 '에코'.

$ test () { ls /tmp; ls /etc/pm; return 5; ls /v*; } ; x=$(test)
$ echo $?
5
$ echo $x
tmux-1000
sleep.d

POWERSHELL은 이것을 다르게합니다.

> function test() { ls; return 5 ; ls } ; $x=test
> echo $?
True
> echo $x
    Directory: c:\foo\bar

Mode                LastWriteTime         Length Name
----                -------------         ------ ----

더 많은 PowerShell 이상한 점 :

Chocolatey는 GODSEND 인 RefreshEnv.cmd를 추가합니다. PowerShell과 함께 제공되지 않는 이유는 무엇입니까? $ env를 재설정하기 위해 쉘을 다시 시작하거나 인터넷에서 바보 같은 스크립트를 다운로드해야하는 이유는 무엇입니까?

@jzabroski 이것은 https://github.com/PowerShell/PowerShell-RFC/pull/92 에서 자랐습니다.

PowerShell 공급자에 대한 표준 개체 모델 만들기 : https://github.com/PowerShell/SHiPS/issues/66#issuecomment -368924485

SHiPS 66 호에 대한 링크에서 가능한 후보 cmdlet에 대해 간략히 설명합니다. 이러한 핵심 cmdlet에 대해 Haskell typeclass 동작과 같은 것을 구현할 수없는 이유가 명확하지 않습니다.

이 API는 이미 PowerShell에 있습니다.

@iSazonov 답장하는 내용을 편집 및 인용하고 언급 된 API 문서에 대한 하이퍼 링크와 같은 컨텍스트를 추가해 주시겠습니까? TYVM

@jzabroski srcSystem.Management.Automationnamespaces 폴더의 파일을 찾습니다.

POWERSHELL은 이것을 다르게합니다.

다르게하는 것은 bash 입니다. return 는 (정수) 프로세스 종료 코드 만 설정할 수 있습니다 (다른 프로그래밍 언어에서 "return"이 의미하는 것이 아니라 exit ). .

PowerShell은으로도 그렇게 할 수 exit 5

프로세스 기반 셸이 아니고 함수가 종료되지 않아야하므로 PowerShell에서 종료 코드를 자주 사용하지 않습니다 (예약 된 작업 및 다른 OS와의 상호 운용에만 거의 적용됨).

하루가 끝나면 stdout 핸들 유형을 감지하는 것이 PowerShell에서 유용하지 않은 이유와 같습니다 (그리고 out-null로 "리디렉션"하는 것이 [void] 로 캐스팅하거나 할당하는 것과 동일하지 않은 이유) $null )

사람들이 실제로 조치를 취하고 싶은 피드백이 있다면 새로운 문제를 제출하는 것이 좋습니다. 팀이 PowerShell의 이전 버전과 호환되지 않는 버전을 _ 명확하고 분명하게 배제 했으므로이 스레드가 계속 진행되는 이유를 모르겠습니다 ...

팀이 _ 명확하고 분명하게 배제 된 _ 버전의 이전 버전과 호환되지 않는

그것은 나에게 뉴스입니다. 이것이 어떻게 분명합니까? 게시물 또는 기타 문서에 대한 링크를 제공하십시오.

우리가 매일 약간의 파손과 씨름하는 동안 "우리는 결코 호환성을 깨지 않을 것입니다"라는 말을 듣는 것은 우리 중 일부에게는 약간 실망 스럽습니다. 이 스레드의 요점은 아이디어의 자유 시장이 업스트림이 그렇지 않을 때 이러한 문제 중 일부를 해결할 수 있다는 것입니다.

누군가는 powershell을 포크하고 최소한의 기술 부채로 버전을 만드는 것이 유리하다는 것을 알 수 있습니다. 그 그룹은이 스레드에 제시된 아이디어로부터 혜택을받을 것입니다. (이것이 지금 세상이 돌아가는 방식입니다. 최고의 파워 쉘이 이길 수 있기를 바랍니다.)

나는 팀이 이미 powershell에서 pwsh로 명령의 이름을 바꾸어 '역방향이 아닌 호환'버전의 powershell을 생산했음을 반복합니다. 힘 (SHELL)은 껍질입니다. 쉘의 역할은 디지털 시스템을 하나로 묶는 인간의 접착제 역할을하는 것입니다. 최소한의 외부 의존성을 가진 컴파일 된 바이너리가 아닙니다. 전통적인 프로그래밍 언어조차도 획기적인 변화를 계획하고 만듭니다.

POWERSHELL은 이것을 다르게합니다.

다르게하는 것은 bash 입니다. return 는 (정수) 프로세스 종료 코드 만 설정할 수 있습니다.

나는 다른 조개가 궁금합니다. 걔들 뭐해? korn, csh 등

다음은 여러 언어로 된 return 문에 대해 설명하는 기사입니다. https://en.wikipedia.org/wiki/Return_statement

운영 체제 [쉘]은 리턴 코드 및 출력과 같은 여러 가지가 리턴되도록 허용합니다.

우리 팀에는 가능한 한 많이 PowerShell 6을 사용하더라도 PowerShell 5에서만 실행되는 다양한 스크립트가 있습니다. 제 경험상 PowerShell이 ​​완전히 이전 버전과 호환된다는 전제는 확실히 거짓입니다. 최소한 몇 가지 극단적 인 경우 (예 : ErrorActionPreference 가 직관적으로 작동하지 않음)는 확실히 브레이킹 체인지로 다루어야합니다.

@chriskuech ErrorActionPreference 대한 문제를 자세히 설명하는 문제가 있습니까?

@ SteveL - MSFT 나는 @KirkMunro 직접 @chriskuech 코멘트를 아래에하는 것은 당신이 찾고있는 문제입니다 연결하는 모자이크를 생각합니다. 그리고 예, 저는 모자이크라는 단어를 기술 대화에 집어 넣습니다.

즉, @iSazonov 는 2018 년 10 월 1 일 @chriskuech 원본 문제를 마감 https://github.com/PowerShell/PowerShell/issues/7774 참조

이런 것들이 다른 형태로 계속 나오고있는 것 같고,위원회는 그에 대한 문제를 계속 마무리하고 있습니다.

@jzabroski 는 근본 원인을 겨냥한 주요 문제를 발견했습니다.

나는 또한 과거에 Invoke-WebRequest 증상 중 하나에 대한 문제를 제기했습니다. 내부 .NET 메서드가 종료 오류를 발생시키기 때문에 발생하는 실패한 HTTP 요청을 처리하기 위해 전체 try / catch 상용구를 완전히 어리석은 사람들을 개인적으로 목격했습니다. 세 가지 사례 각각에서 엔지니어는 근본적인 동작과 문제가 해결되지 않는 이유를 설명 할 때 욕설로 응답했습니다.

요약하면 , 종료 오류는 스크립트를 종료하는 이유는 PowerShell 작성자는 스크립트가 논리적으로 오류를 넘어서 진행할 수 없다고 믿기 때문입니다. 그러나 나는 그것이 문자 그대로 스크립트 작성자가 사례별로 결정한 것 외에는 아무도 생각하지 않습니다. 스크립터 만 스크립트를 Stop , SilentlyContinue , Continue 등으로 지정할 수 있습니다.

(위의 문제에 대한 접선)

PowerShell이 ​​옵트 인 "ZeroTechDebt"모드를 구현하는 경우 $ErrorActionPreference = "Stop" 가 기본적으로 설정되어야한다고 생각합니다. 분명히이 설정은 REPL에서 의미가 없으므로 모든 시나리오에 대해 기본적으로 설정되어서는 안됩니다. 그러나 말 그대로 모든 스크립트에 $ErrorActionPreference = "Stop" 접두사를 붙여 "방어 프로그래밍"을 활성화하고 "보통"처럼 작동합니다. " 프로그래밍 언어.

@chriskuech 아직하지 않았다면이 RFC 컬렉션을 살펴보세요 : https://github.com/PowerShell/PowerShell-RFC/pull/187. 그들은 PowerShell의 새로운 제로 기술 부채 버전이 필요하지 않고 여기서 말하는 내용을 직접 말합니다.

읽기 / 다이제스트가 더 쉬워지면 해당 저장소의 문제 페이지에서 별도의 문제에서 4 개의 RFC를 찾을 수도 있습니다. 내가 게시 한 미해결 문제를 찾으면 찾을 수 있습니다.

@ SteveL-MSFT 여기 내 생산성을 저해하는 유사한 문제가 있습니다. $ErrorActionPreference 아니라 $ConfirmPreference .

아래는 SQL Server 디스크 볼륨을 64kb로 설정하기 위해 작성한 추악한 스크립트입니다.

Import-Module Storage;

function Format-Drives
{
    # See https://stackoverflow.com/a/42621174/1040437 (Formatting a disk using PowerShell without prompting for confirmation)
    $currentconfirm = $ConfirmPreference
    $ConfirmPreference = 'none'

    Get-Disk | Where isOffline | Set-Disk -isOffline $false
    # The next line of this script is (almost) copy-pasted verbatim from: https://blogs.technet.microsoft.com/heyscriptingguy/2013/05/29/use-powershell-to-initialize-raw-disks-and-to-partition-and-format-volumes/
    Get-Disk | Where partitionstyle -eq 'raw' | Initialize-Disk -PartitionStyle MBR -Confirm:$false -PassThru | New-Partition -AssignDriveLetter -UseMaximumSize -IsActive | Format-Volume -FileSystem NTFS -AllocationUnitSize 64kb -Confirm:$false

    # See https://stackoverflow.com/a/42621174/1040437 (Formatting a disk using PowerShell without prompting for confirmation)
    $ConfirmPreference = $currentconfirm
}

Format-Drives

몇 가지 측면 포인트 :

1. Format-Volume 대한 문서는 더 많은 것을 원합니다. 두 가지 예만? 공식 문서는 https://github.com/MicrosoftDocs/windows-powershell-docs/issues/1170 웹 사이트와 동기화되지 않습니다.
2. 스크립팅 언어에 대한 GUI를 피하는 방법을 배우기 위해 StackOverflow로 이동해야하는 이유는 무엇입니까?
3. 이것이 오류가 발생하기 쉬우 며 "생각없이"작성하기가 어리석은 일이지만 https://github.com/PowerShell/PowerShell-RFC/issues/198 과 같은 관련 문제에 밑줄을 긋기 만하면됩니다. 이것은 "에서 Bruce Payette의 약속에 대한 또 다른 예입니다." "PowerShell In Action"은 옳다고 생각하는 것을 입력하기 만하면 작동합니다. 완전히 거짓입니다.
4. @ mklement0 의 문제도 참조하십시오 : https://github.com/PowerShell/PowerShell/issues/4568

-Version은 최대 버전을 지정할 방법이 없습니다.

참조 : https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_requires?view=powershell-6

.NET Framework와 .NET Core간에 API가 완전히 다른 경우 (예 : AccessControl API의 작동 방식) .NET Framework 라이브러리를로드하는 고급 함수를 작성할 때 이는 성가신 일입니다.

@jzabroski 그러나 에디션을 지정하여 있습니다 .

#requires -PSEdition Desktop
# versus
#requires -PSEdition Core

@rjmholt 가 주요 변경 사항을 구현하고 관리하는 방법에 대한 토론을 공식적으로 시작했습니다. # 13129.

또한 # 6817 및 # 10967은 주요 변경 사항이 허용되면 다시 방문 할 가치가있는 행동입니다.
(https://github.com/PowerShell/PowerShell/issues/10967#issuecomment-561843650에 설명 된 동일한 근본 원인이 있습니다).

PowerShell은 숫자보다 목록에 더 가깝기 때문에 , 이 + 보다 강력하다는 사실은 논리적입니다. IMHO.

@rjmholt 가 공식적으로 토론을 시작했습니다

다른 어떤 토론보다 더 공식적이지 않다고 말해야합니다

가져 오기 및 함수 서명 편집 시간에 대한 엄격한 검사를 받고 싶습니다.
EcmaScript 모듈이 제공하는 새로운 가져 오기 의미 체계를 도입 할 계획입니까?
더 이상 글로벌 네임 스페이스 오염이 없습니다. 느린 가져 오기 메커니즘.