Windows PowerShell

윈도우의 좋지 않은 점을 꼽으라면, 윈도우는 다른 운영체제의 이것저것을 표절해오면서 커왔기 때문에 자신의 색이 없다는 것이다. 지금은 .NET이 등장하면서 윈도우는 그동안 중구난방, 중복에 표절, 이런 것에서 벗어나 자신의 색을 찾은 느낌이다. OLE, COM, COM+로 발전해오면서 윈도우가 추구하는 방향이 어느 정도 잡혔다면, .NET에서는 완전히 자신의 색이 뚜렷하게 보이는 점은 매우 기쁘게 생각하는데..

그것 외에 또 하나 불만이라면 윈도우의 스크립팅 환경은 아주 열악하다는 것이다. 유닉스 쉘의 우아한 처리와는 비교할 수 없는 저급한 MS-DOS 시절의 유산이 그대로 지속되고 있어서 답답하기 그지없었다. 이것이 싫다면 4DOS나 4NT와 같은 써드파티 유틸리티를 사용하는 것인데, 이것 역시 MS-DOS 유산의 확장에 지나지 않는다는 문제가 있다. 즉, 유닉스 쉘이 보여주는, 프로세스의 입출력을 파이프로 연결한다든지, 함수 흉내를 낸다든지, 실질적인 어떤 스크립팅 작업을 할 수 있는 수단이 없었다. 사실, 이것은 .NET이 등장하기 전까지 근본적으로 해결이 가능한 문제가 아니었다.

그런데, Windows PowerShell의 등장으로, 더 이상 유닉스 쉘 환경을 부러워 할 필요가 없어졌다. 드디어, 가장 원했던 윈도우에 맞는 새로운 쉘, 진정한 윈도우 스크립팅 쉘인 것이다! 정말로, 이렇게 윈도우가 '표절 운영체제'가 아니라, '따라하면서도', 자신의 색을 찾는 것은 정말로 축하해줄 일이 아닐 수 없다. 또, 텍스트 처리를 하는 것이 아니라, 개체를 처리하며, 내부적으로 커맨드릿이라는 작은 개체들을 만들 수 있는 것도 좋다. 이게 지원이 안되면 내부 명령어 몇 개와 무수히 많은 외부 유틸리티가 필요해지기 때문이다. 유닉스에서는, 정말 자그마한 일을 하는 프로그램도 전부 프로그램으로 분리되어 있다보니, 구조는 명료하지만 너무 산만하다는 느낌을 감출 수 없었다. WSH(Windows Scripting Host)도 괜찮은 툴이었지만, 이것은 스크립트 처리를 위한 기능만을 가지고 있어서, Cmd.exe를 완전히 대체할 수 없었다.

PowerShell을 사용할 때 한가지 주의할 점은, PowerShell은 명령 모드와 식 모드로 나뉘어진다는 것이다. 즉, 7za.exe라는 파일을 실행하고 싶을 때, 프롬프트에 7za라고 입력해봤자 실행되지 않는다. 실행 파일의 이름이 숫자로 시작하기 때문에 상수나 변수로 인식하며, 식 모드로 실행된다. 정상적으로 파일을 실행하고 싶다면, 명령 모드를 명시적으로 지정하는 .나 &를 써줘야 한다. 즉, . 7za라고 입력하거나, & 7za라고 입력하면 원하는대로 동작할 것이다.