로딩
요청 처리 중입니다...

PowerShell 강력하게 쓰기 — 예쁜 프롬프트, 퍼지 히스토리 검색, kubectl/docker 자동완성

 PowerShell 강력하게 쓰기 — 예쁜 프롬프트, 퍼지 히스토리 검색, kubectl/docker 자동완성

버전에 따른 차이가 성능과 동작 신뢰성에 결정적 영향을 준다. Invoke-FzfPsReadlineHandlerProvider 와 Invoke-FzfPsReadlineHandlerHistory 함수가 2.7.10부터 export되므로, 해당 버전 이상에서만 외부에서 직접 접근 가능한 핸들러로 작동한다. 2.6.x 이하에서는 이들 함수가 내부 함수로 남아 있어 글의 autoloading 방식이 제대로 작동하지 않는다. 따라서 설치 직후 버전을 확인하고, 필요 시 적합한 버전으로 맞춰야 한다.

starship 의 초기화 방식도 품질에 직접적인 영향을 준다. 공식 문서의 Invoke-Expression (&starship init powershell) 방식은 starship 을 두 차례 실행하는 구조여서 1차 실행이 2차 실행을 호출하는 코드 출력으로 이어진다. 여기에 --print-full-init 옵션을 붙이면 최종 초기화 코드가 바로 출력되어 실행이 한 번으로 감소하고, starship 자체의 오버헤드도 대략 절반 수준으로 줄어든다.

PSFzf 의 모듈 자동 로딩 기능은 PowerShell 3.0+의 특징을 활용한다. 모듈이 export한 함수를 호출하면 자동으로 모듈이 임포트되는 동작이 존재하고, PSFzf 2.7.10부터 PSReadLine 핸들러 함수가 export되므로 프로필에서 Import-Module PSFzf 를 제거하고 키에 함수만 매핑해 두면 첫 단축키 누름 시점에 모듈이 자동으로 로드된다. PSFzf 의 로딩은 5.1 기준 1초 이상 걸리는 작업이므로, 이 한 줄 제거 효과가 상당하다.

kubectl 과 docker 의 New-Module 동적 모듈 격리는 완전한 격리와 안정성을 갖게 한다. cobra 기반의 completion 스크립트가 헬퍼 함수를 completer 블록 밖에 정의하는 문제가 생길 경우, 이를 함수나 ScriptBlock 안에서 Invoke-Expression 으로 lazy 로드하면 헬퍼가 임시 스코프에 정의되어 사라져 두 번째 탭 이후 자동완성이 깨질 수 있다. 해결책은 전체 스크립트를 New-Module 안에서 실행해 모듈 세션 상태에 헬퍼를 바인딩하고, Export-ModuleMember 의 빈 호출로도 아무것도 내보내지 않아 세션 오염이 없도록 하는 것. 여러 도구의 완료 스크립트가 같은 변수명이나 함수명을 사용하더라도 각 모듈의 격리로 충돌이 발생하지 않는다. 스크립트 내부의 Register-ArgumentCompleter 는 엔진 전역에 등록되므로 두 번째 탭부터는 lazy 래퍼를 거치지 않고 실제 completer로 바로 연결된다. 첫 탭의 결과는 TabExpansion2 재호출로 위임되며, 도구마다 다른 내부 변수명에 의존하지 않아서 구식과 신식 kubectl, docker 구성 모두에서 호환된다.

# docker # 터미널 # 자동완성 # 개발환경 # starship # PSFzf # PowerShell # kubectl # fzf # 파워셸