about_Path_Syntax — PowerShell 경로 문법 이해하기
about_Path_Syntax — PowerShell 경로 문법 이해하기
파일이나 폴더를 콘솔에서 찾으려고 하다 보면 C:\Windows\System32\Shell.dll 같은 긴 경로를 마주치게 돼요. 이 문서는 PowerShell이 경로를 어떻게 해석하는지, 그리고 완전한 경로(full path) 와 상대 경로(relative path) 가 언제 어떻게 쓰이는지를 차근차근 설명해 주는 글입니다. 처음 보는 명령어는 하나씩 따라쳐 보면서 읽으면 훨씬 잘 들어와요.
본문
짧은 설명 (Short description)
PowerShell의 완전 경로와 상대 경로 형식을 설명해요.
긴 설명 (Long description)
PowerShell 공급자(provider)를 통해 접근할 수 있는 데이터 저장소의 모든 항목은 경로 이름으로 유일하게 식별돼요. 경로는 항목 이름, 그 항목이 들어 있는 컨테이너와 하위 컨테이너, 그리고 그 컨테이너들에 접근할 때 사용하는 PowerShell 드라이브를 합쳐 놓은 것이에요.
PowerShell의 경로 이름은 두 종류로 나뉘어요 — 완전 경로(fully qualified) 와 상대 경로(relative). 완전 경로는 경로를 이루는 모든 요소를 다 담고 있어요. 다음 문법이 완전 경로의 요소를 보여줘요:
[<provider>::]<drive>:[\\<container>[\\<subcontainer>...]]\\<item>
<provider> 자리는 데이터 저장소에 접근할 때 쓰는 PowerShell 공급자를 가리켜요. 예를 들어 FileSystem 공급자는 컴퓨터의 파일과 디렉터리에 접근하게 해 주죠. 그런데 이 요소는 선택 사항이라 거의 신경 쓸 필요가 없어요. 드라이브 이름이 모든 공급자에 걸쳐 유일하기 때문이에요.
<drive> 자리는 특정 PowerShell 공급자가 제공하는 PowerShell 드라이브를 가리켜요. FileSystem 공급자의 경우, PowerShell 드라이브는 시스템에 구성된 Windows 드라이브와 대응돼요. 예를 들어 시스템에 A: 드라이브와 C: 드라이브가 있다면, FileSystem 공급자가 PowerShell 안에 똑같은 드라이브를 만들어 줘요.
드라이브를 지정하고 나면, 항목을 담고 있는 컨테이너와 하위 컨테이너를 지정해야 해요. 컨테이너는 데이터 저장소에 존재하는 계층 순서대로 써야 해요. 다시 말해, 부모 컨테이너부터 시작해서 그 안의 자식 컨테이너로, 또 그 패턴을 자식마다 반복해야 하죠. 그리고 각 컨테이너 앞에는 백슬래시(\) 를 붙여야 해요.
참고 PowerShell은 다른 플랫폼에서의 PowerShell과 호환되도록 백슬래시(
\)나 슬래시(/)를 모두 쓸 수 있게 해 줘요. 이건 PowerShell 명령에서 잘 동작하지만, 자기 플랫폼의 기본 디렉터리 구분자만 기대하는 네이티브 애플리케이션에서는 안 통할 수 있어요. 내 플랫폼에서 쓰는 문자를 확인하고 싶다면[System.IO.Path]::DirectorySeparatorChar를 사용하면 돼요.
컨테이너와 하위 컨테이너를 지정한 뒤에는, 백슬래시를 앞에 붙여 항목 이름을 제공해야 해요. 예를 들어 C:\Windows\System32 디렉터리에 있는 Shell.dll 파일의 완전 경로는 다음과 같아요:
C:\Windows\System32\Shell.dll
이 경우 컨테이너에 접근할 때 쓰는 드라이브는 C: 드라이브, 최상위 컨테이너는 Windows, 하위 컨테이너는 System32, 그 안의 항목은 Shell.dll이 되는 거예요.
상대 경로가 필요한 상황
어떤 상황에서는 완전 경로를 다 쓸 필요 없이 상대 경로로 줄여 쓸 수 있어요. PowerShell은 항목을 현재 작업 위치에 상대적으로 식별하도록 해 주거든요.
PowerShell이 상대 경로를 지정할 때 쓰는 문자 시퀀스는 다음과 같아요:
(.)— 현재 위치(..)— 현재 위치의 부모(\)— 현재 위치의 루트
다음 예시들은 현재 작업 디렉터리가 C:\Windows로 설정돼 있다고 가정해요:
- 상대 경로
.\System→C:\Windows\System으로 해석돼요 - 상대 경로
..\Program Files→C:\Program Files로 해석돼요 - 상대 경로
\Program Files→C:\Program Files로 해석돼요 - 상대 경로
System→C:\Windows\System으로 해석돼요
명령에서 경로를 쓸 때는 완전 경로나 상대 경로 중 편한 쪽을 쓰면 돼요. 예를 들어 현재 작업 디렉터리가 C:\Windows라고 해 볼게요. 다음 Get-ChildItem 명령은 C:\TechDocs 디렉터리의 모든 항목을 가져와요:
Get-ChildItem \TechDocs
여기서 백슬래시는 현재 작업 위치의 드라이브 루트를 쓰라는 뜻이에요. 작업 디렉터리가 C:\Windows니까 드라이브 루트는 C: 드라이브가 되고, TechDocs 디렉터리가 루트에 있으니까 백슬래시만 지정해 주면 되는 거예요.
같은 결과를 완전 경로로 써도 돼요:
Get-ChildItem C:\TechDocs
완전 경로를 쓰든 상대 경로를 쓰든, 경로가 중요한 이유는 항목을 찾아주기 때문만이 아니에요. 다른 컨테이너에 같은 이름의 항목이 있어도, 경로가 그 항목을 유일하게 식별해 주기 때문이에요.
예를 들어 이름이 각각 Results.txt인 파일 두 개가 있다고 해 볼게요. 첫 파일은 C:\TechDocs\Jan 디렉터리에, 두 번째 파일은 C:\TechDocs\Feb 디렉터리에 있어요. 첫 파일의 경로(C:\TechDocs\Jan\Results.txt)와 두 번째 파일의 경로(C:\TechDocs\Feb\Results.txt)는 두 파일을 명확하게 구분해 줘요.
Win32 파일 네임스페이스 지원
Windows에서는 FileSystem 공급자를 지원하는 cmdlet들이 Win32 파일 네임스페이스 형식을 쓰는 경로도 지원해요. 단, 이런 경로는 cmdlet의 LiteralPath 매개 변수에서만 쓸 수 있어요.
Win32 파일 네임스페이스의 경로는 \\?\ 접두사로 시작해요. 이 접두사는 Windows API가 모든 문자열 파싱을 끄고 그 뒤에 오는 문자열을 파일 시스템에 그대로 보내도록 해 줘요. 예를 들어 파일 시스템이 큰 경로와 긴 파일 이름을 지원한다면, Windows API가 평소에는 적용하던 MAX_PATH 제한을 넘어설 수 있어요.
더 자세한 내용은 Naming Files, Paths, and Namespaces — Win32 File Namespaces 문서를 참고하세요.