경로 조작

경로 조작 (Manipulating Paths)

Racket에서 경로(path)를 다루는 다양한 함수를 설명하는 문서예요. 경로 값과 문자열/바이트 문자열 사이의 변환, 경로 결합, 경로 정리(cleanse/simplify), 그리고 경로 분해와 확장자 처리까지 살펴볼게요.

출처: Racket Reference

본문

procedure
(path? v) → boolean?
  v : any/c

v가 현재 플랫폼에 대한 경로 값(문자열이 아니고, 다른 플랫폼에 대한 경로도 아님)이면 #t, 그렇지 않으면 #f를 반환합니다.

procedure
(path-string? v) → boolean?
  v : any/c

v가 경로 또는 문자열이면 #t를 반환합니다: 현재 플랫폼에 대한 경로이거나, nul 문자를 포함하지 않는 비어 있지 않은 문자열이면요. 그렇지 않으면 #f를 반환합니다.

procedure
(path-for-some-system? v) → boolean?
  v : any/c

v가 어떤 플랫폼에 대한 경로 값(문자열 아님)이면 #t, 그렇지 않으면 #f를 반환합니다.

procedure
(string->path str) → path?
  str : string?

Unix와 Mac OS에서는 (string->bytes/locale str (char->integer #\?)), Windows에서는 (string->bytes/utf-8 str)이 바이트 문자열 인코딩인 경로를 만듭니다.

주의하세요: 현재 로케일(locale)이 모든 문자열을 인코딩하지 못할 수 있으며, 그 경우 string->path가 서로 다른 str에 대해 같은 경로를 만들 수 있습니다. 문자열이 단일 경로 요소(path element)를 나타낼 때 string->path 대신 사용해야 하는 string->path-element도 참고하세요. 문자열과 바이트 문자열이 경로를 어떻게 인코딩하는지에 대한 정보는 "Unix Path Representation"과 "Windows Path Representation"을 참고하세요.

string->some-system-path도 참고하고, 문자열이 경로를 어떻게 인코딩하는지에 대한 정보는 "Unix Path Representation"과 "Windows Path Representation"을 참고하세요.

base 패키지의 6.1.1.1 버전에서 변경됨: Windows 변환이 항상 UTF-8을 사용하도록 변경되었습니다.

procedure
(bytes->path bstr [type]) → path?
  bstr : bytes?
  type : (or/c 'unix 'windows) = (system-path-convention-type)

(어떤 플랫폼에 대한) 바이트 문자열 인코딩이 bstr인 경로를 만듭니다. 여기서 bstr은 nul 바이트를 포함하면 안 됩니다. 선택적인 type은 경로에 사용할 규약(convention)을 지정합니다.

리터럴에서 상대 경로 요소를 변환할 때는 대신 bytes->path-element를 사용하세요. 그것은 개별 요소에 적합한 인코딩을 적용합니다.

바이트 문자열이 경로를 어떻게 인코딩하는지에 대한 정보는 "Unix Path Representation"과 "Windows Path Representation"을 참고하세요.

procedure
(path->string path) → string?
  path : path?

Unix와 Mac OS에서는 path의 바이트 문자열 인코딩을 현재 로케일로 디코딩하고, Windows에서는 UTF-8을 사용해 path를 나타내는 문자열을 만듭니다. 전자의 경우, 인코딩이 실패하는 곳에서 결과 문자열에 ?가 사용되며, 인코딩 결과가 빈 문자열이면 결과는 "?"입니다.

결과 문자열은 사용자에게 표시하거나, 문자열 정렬(string-ordering) 비교 등에 적합하지만, string->path를 통해 (수정된) 경로를 다시 만드는 데는 적합하지 않습니다. 디코딩과 재인코딩이 경로의 바이트 문자열 정보를 잃을 수 있기 때문이에요.

게다가 개별 경로 요소에 기반한 표시와 정렬(예: 경로가 없는 파일 이름)을 위해서는 path-element->string을 대신 사용해서, 일부 상대 경로를 나타내는 데 사용되는 특수 인코딩을 피하세요. Windows 경로 변환에 대한 구체적인 정보는 "Windows Paths"를 참고하세요.

some-system-path->string도 참고하세요.

base 패키지의 6.1.1.1 버전에서 변경됨: Windows 변환이 항상 UTF-8을 사용하도록 변경되었습니다.

procedure
(path->bytes path) → bytes?
  path : path-for-some-system?

path의 바이트 문자열 표현을 만듭니다. 이 변환에서는 정보가 유실되지 않으므로, (bytes->path (path->bytes path) (path-convention-type path))는 항상 pathequal?인 경로를 만듭니다. path 인자는 어떤 플랫폼의 경로일 수 있습니다.

바이트 값으로의/로부터의 변환은 경로를 마샬링(marshaling)하고 언마샬링하는 데 유용하지만, 경로의 바이트 형태를 조작하는 것은 일반적으로 실수입니다. 특히 바이트 문자열은 Windows 경로에 대해 \\?\REL 인코딩으로 시작할 수 있어요. path->bytes 대신, 개별 경로 요소를 조작하려면 split-pathpath-element->bytes를 사용하세요.

바이트 문자열이 경로를 어떻게 인코딩하는지에 대한 정보는 "Unix Path Representation"과 "Windows Path Representation"을 참고하세요.

procedure
(string->path-element str [false-on-non-element?]) → (or/c (and/c path? path-element?) #f)
  str : string?
  false-on-non-element? : any/c = #f

string->path와 같지만, str이 경로의 단일 상대 요소에 해당하며, 경로로 변환하기 위해 필요에 따라 인코딩됩니다. 경로 변환에 대한 자세한 정보는 "Unix and Mac OS Paths"와 "Windows Paths"를 참고하세요.

str이 어떤 경로 요소에도 해당하지 않거나(예: 절대 경로이거나 쪼갤 수 있는 경우), Unix와 Mac OS에서 업-디렉토리(up-directory) 또는 같은-디렉토리(same-directory) 표시에 해당하면, #f가 반환되거나 exn:fail:contract 예외가 일어납니다. #ffalse-on-non-element?가 참일 때만 반환됩니다.

path->string처럼, 로케일 특정 변환에서 str에서 정보가 유실될 수 있습니다.

base 패키지의 8.1.0.6 버전에서 변경됨: false-on-non-element? 인자가 추가되었습니다.

procedure
(bytes->path-element bstr [type false-on-non-element?]) → (or/c path-element? #f)
  bstr : bytes?
  type : (or/c 'unix 'windows) = (system-path-convention-type)
  false-on-non-element? : any/c = #f

bytes->path와 같지만, bstr이 경로의 단일 상대 요소에 해당합니다. 변환, bstr에 대한 제약, 그리고 false-on-non-element?의 처리 측면에서 bytes->path-elementstring->path-element과 같습니다.

bytes->path-element 프로시저는 일반적으로 다른 경로(그 경로는 split-pathpath-element->bytes로 분해됨)에 기반해 경로를 재구성할 때, 경로 요소의 ASCII 수준 조작이 필요할 때 최선의 선택입니다.

base 패키지의 8.1.0.6 버전에서 변경됨: false-on-non-element? 인자가 추가되었습니다.

procedure
(path-element->string path) → string?
  path : path-element?

path->string과 같지만, split-path가 그렇듯 뒤따르는 경로 구분자가 제거됩니다. Windows에서는 \\?\REL 인코딩 접두어도 제거됩니다; 자세한 내용은 "Windows Paths"를 참고하세요.

path 인자는 split-path를 적용했을 때 첫 번째 결과로 'relative를, 두 번째 결과로 경로를 반환하도록 되어 있어야 합니다. 그렇지 않으면 exn:fail:contract 예외가 일어납니다.

path-element->string 프로시저는 일반적으로 경로가 없는 파일이나 디렉토리 이름을 사용자에게 제시할 때 최선의 선택입니다.

procedure
(path-element->bytes path) → bytes?
  path : path-element?

path->bytes와 같지만, path-element->string에서처럼 인코딩 접두어 등이 제거됩니다.

합리적인 로케일에서, path의 인쇄된 형태의 연속된 ASCII 문자들은 각 문자의 코드 포인트 값과 일치하는 연속된 바이트 값으로 매핑되며, 앞이나 뒤의 ASCII 문자는 각각 앞이나 뒤의 바이트로 매핑됩니다. path 인자는 어떤 플랫폼의 경로일 수 있습니다.

path-element->bytes 프로시저는 일반적으로 (ASCII 수준에서 조작하기 위해) 경로의 내용을 추출한 다음, bytes->path-elementbuild-path로 결과를 재조립할 때 split-path와 함께 올바른 선택입니다.

procedure
(path<? a-path b-path ...) → boolean?
  a-path : path?
  b-path : path?

각 경로 쌍에 대한 비교가 path->bytesbytes<?를 사용한 것과 같은 인자들이 정렬되어 있으면 #t를 반환합니다.

base 패키지의 7.0.0.13 버전에서 변경됨: 둘 이상을 허용하는 것에 더해 한 인자도 허용합니다.

procedure
(path-convention-type path) → (or/c 'unix 'windows)
  path : path-for-some-system?

경로 값(문자열 아님)을 받아서 그 규약 타입을 반환합니다.

procedure
(system-path-convention-type) → (or/c 'unix 'windows)

현재 플랫폼의 경로 규약 타입을 반환합니다: Unix와 Mac OS는 'unix, Windows는 'windows입니다.

procedure
(build-path base sub ...) → path-for-some-system?
  base : (or/c path-string? path-for-some-system? 'up 'same)
  sub : (or/c (and/c (or/c path-string? path-for-some-system?) (not/c complete-path?))
              (or/c 'up 'same))

기본 경로와 임의의 수의 하위 경로 확장이 주어졌을 때 경로를 만듭니다. base가 절대 경로이면 결과는 절대 경로이고, 그렇지 않으면 결과는 상대 경로입니다.

base와 각 sub는 상대 경로, 'up 심볼(상대 부모 디렉토리를 나타냄), 또는 'same 심볼(상대 현재 디렉토리를 나타냄) 중 하나여야 합니다. Windows 경로의 경우, base가 드라이브 지정(뒤따르는 슬래시가 있거나 없이)이면 첫 번째 sub는 (드라이브 없는) 절대 경로일 수 있습니다. 모든 플랫폼에서 마지막 sub는 파일 이름일 수 있습니다.

basesub 인자는 어떤 플랫폼의 경로일 수 있습니다. 결과 경로의 플랫폼은 basesub 인자에서 추론되는데, 문자열 인자는 현재 플랫폼의 경로를 함의합니다. 서로 다른 인자들이 서로 다른 플랫폼을 위한 것이라면 exn:fail:contract 예외가 일어납니다. 어떤 인자도 플랫폼을 함의하지 않으면(즉 모두 'up이나 'same이면), 생성된 경로는 현재 플랫폼을 위한 것입니다.

subbase는 선택적으로 디렉토리 구분자로 끝날 수 있습니다. 마지막 sub가 구분자로 끝나면, 그것은 결과 경로에 포함됩니다.

basesub가 (비어 있거나 nul 문자를 포함하기 때문에) 불법 경로 문자열이면, exn:fail:contract 예외가 일어납니다.

build-path 프로시저는 경로의 유효성을 검사하거나 파일시스템에 접근하지 않고 경로를 만듭니다.

경로 구성에 대한 자세한 정보는 "Unix and Mac OS Paths"와 "Windows Paths"를 참고하세요.

다음 예시는 Unix 예시에서 현재 디렉토리가 "/home/joeuser"이고 Windows 예시에서 "C:\Joe's Files"라고 가정합니다.

(define p1 (build-path (current-directory) "src" "racket"))
; Unix: p1 is "/home/joeuser/src/racket"
; Windows: p1 is "C:\\Joe's Files\\src\\racket"
(define p2 (build-path 'up 'up "docs" "Racket"))
; Unix: p2 is "../../docs/Racket"
; Windows: p2 is "..\\..\\docs\\Racket"
(build-path p2 p1)
; Unix and Windows: raises exn:fail:contract ; p1 is absolute
(build-path p1 p2)
; Unix: is "/home/joeuser/src/racket/../../docs/Racket"
; Windows: is "C:\\Joe's Files\\src\\racket\\..\\..\\docs\\Racket"
procedure
(build-path/convention-type type base sub ...) → path-for-some-system?
  type : (or/c 'unix 'windows)
  base : (or/c path-string? path-for-some-system? 'up 'same)
  sub : (or/c (and/c (or/c path-string? path-for-some-system?) (not/c complete-path?))
              (or/c 'up 'same))

경로 규약 타입이 명시적으로 지정된다는 점을 제외하면 build-path와 같습니다.

build-path와 마찬가지로, basesub에 대한 어떤 문자열 인자든 다른 것들과 결합되기 전에 암묵적으로 현재 플랫폼의 경로로 변환된다는 점에 유의하세요. 이런 이유로 현재 플랫폼이 아닌 다른 플랫폼을 위해 문자열들로 경로를 만드는 데 이 함수를 사용할 수 없습니다; 그러한 시도에서는 type이 문자열들에 대한 추론된 규약 타입과 일치하지 않아 exn:fail:contract 예외가 일어납니다. (외부 플랫폼을 위한 경로를 만들려면 bytes->path를 참고하세요.)

build-path/convention-typebuild-path보다 유용한 경우는 하위 경로가 'same이나 'up 요소를 포함하는 경우로 제한됩니다.

procedure
(absolute-path? path) → boolean?
  path : (or/c path? string? path-for-some-system?)

path가 절대 경로이면 #t, 그렇지 않으면 #f를 반환합니다. path 인자는 어떤 플랫폼의 경로일 수 있습니다. path가 (예: nul 문자를 포함하는) 불법 경로 문자열이면 #f가 반환됩니다. 이 프로시저는 파일시스템에 접근하지 않습니다.

procedure
(relative-path? path) → boolean?
  path : (or/c path? string? path-for-some-system?)

path가 상대 경로이면 #t, 그렇지 않으면 #f를 반환합니다. path 인자는 어떤 플랫폼의 경로일 수 있습니다. path가 불법 경로 문자열이면 #f가 반환됩니다. 이 프로시저는 파일시스템에 접근하지 않습니다.

procedure
(complete-path? path) → boolean?
  path : (or/c path? string? path-for-some-system?)

path가 완전히 결정된 경로(디렉토리나 드라이브에 상대적이지 않은)이면 #t, 그렇지 않으면 #f를 반환합니다. path 인자는 어떤 플랫폼의 경로일 수 있습니다. Windows 경로의 경우, 절대 경로는 드라이브 지정을 생략할 수 있는데, 그 경우 경로는 상대적이지도 완전하지도 않습니다. path가 불법 경로 문자열이면 #f가 반환됩니다.

이 프로시저는 파일시스템에 접근하지 않습니다.

procedure
(path->complete-path path [base]) → path-for-some-system?
  path : (or/c path-string? path-for-some-system?)
  base : (or/c path-string? path-for-some-system?) = (current-directory)

path를 완전한 경로로 반환합니다. path가 이미 완전한 경로이면 결과로 반환됩니다. 그렇지 않으면 path는 완전한 경로 base에 대해 해석됩니다. base가 완전한 경로가 아니면 exn:fail:contract 예외가 일어납니다.

pathbase 인자는 어떤 플랫폼의 경로일 수 있습니다. 서로 다른 플랫폼을 위한 것이라면 exn:fail:contract 예외가 일어납니다.

이 프로시저는 파일시스템에 접근하지 않습니다.

procedure
(path->directory-path path) → path-for-some-system?
  path : (or/c path-string? path-for-some-system?)

path가 구문상으로 디렉토리를 가리키고 구분자로 끝나면 path를 반환하고, 그렇지 않으면 디렉토리를 지정하고 구분자로 끝나는 path의 확장된 버전을 반환합니다. 예를 들어, Unix와 Mac OS에서 경로 "x/y/"는 구문상으로 디렉토리를 가리키고 구분자로 끝나지만, "x/y""x/y/"로, "x/..""x/../"로 확장됩니다. path 인자는 어떤 플랫폼의 경로일 수 있고, 결과는 같은 플랫폼을 위한 것입니다.

이 프로시저는 파일시스템에 접근하지 않습니다.

procedure
(resolve-path path) → path?
  path : path-string?

path를 정화(cleanse)하고 path와 같은 파일이나 디렉토리를 가리키는 경로를 반환합니다. path가 다른 경로에 대한 소프트 링크이면 가리켜진 경로가 반환되고(이것은 path를 소유한 디렉토리에 대해 상대적인 경로일 수 있음), 그렇지 않으면 path가 (정화 후에) 반환됩니다.

Windows에서는 링크에 대한 경로가 구문적으로 단순화되어야 하므로, 업-디렉토리 표시는 앞선 요소 자체가 링크를 가리키는지 여부와 무관하게 앞선 경로 요소를 제거합니다. 상대-경로 링크의 경우 경로가 특별히 파싱되어야 합니다; 자세한 내용은 "Windows Paths"를 참고하세요.

base 패키지의 6.0.1.12 버전에서 변경됨: Windows의 링크 지원이 추가되었습니다.

procedure
(cleanse-path path) → path-for-some-system?
  path : (or/c path-string? path-for-some-system?)

파일시스템을 고려하지 않고 (이 장의 시작 부분에서 설명한 대로) path를 정화합니다.

예시:

> (let ([p (string->some-system-path "tiny//dancer" 'unix)])
    (cleanse-path p))
#<path:tiny/dancer>
procedure
(expand-user-path path) → path?
  path : path-string?

path를 정화합니다. 추가로, Unix와 Mac OS에서 앞에 오는 ~는 사용자의 홈 디렉토리로 취급되어 확장됩니다. 사용자 이름은 ~(/ 앞이나 경로 끝에서)를 따릅니다. 여기서 ~ 단독은 현재 사용자의 홈 디렉토리를 나타냅니다.

procedure
(simplify-path path [use-filesystem?]) → path-for-some-system?
  path : (or/c path-string? path-for-some-system?)
  use-filesystem? : boolean? = #t

path의 중복 경로 구분자(단일 뒤따르는 구분자는 제외), 업-디렉토리 .., 같은-디렉토리 . 표시를 제거하고, Windows 경로에서 / 구분자를 \ 구분자로 바꿔서, 결과가 (존재한다면) path와 같은 파일이나 디렉토리에 접근하도록 합니다.

일반적으로 경로 이름은 가능한 한 정규화됩니다 — use-filesystem?#f이면 파일시스템을 고려하지 않고, (Windows에서) 경로 안의 문자의 대소문자를 바꾸지 않습니다. path가 구문상으로 디렉토리를 가리키면 결과는 디렉토리 구분자로 끝납니다.

path가 단지 슬래시를 백슬래시로 바꾸는 것 이상으로 단순화되고 use-filesystem?가 참(기본값)이면, 완전한 경로가 반환됩니다. path가 상대적이면 현재 디렉토리에 대해 해석됩니다. Unix와 Mac OS에서는 업-디렉토리 표시가 소프트 링크를 고려해 제거됩니다(그래서 결과 경로가 이전과 같은 디렉토리를 가리키도록); Windows에서는 업-디렉토리 표시가 앞선 경로 요소를 삭제함으로써 제거됩니다.

use-filesystem?#f이면, 업-디렉토리 표시는 앞선 경로 요소를 삭제함으로써 제거되고, 결과는 경로 시작 부분에 남아 있는 업-디렉토리 표시가 있는 상대 경로일 수 있습니다. 업-디렉토리 표시가 루트 디렉토리의 부모를 가리킬 때는 버려집니다. 마찬가지로, 업-디렉토리 표시를 제거했을 때 같은-디렉토리 표시만 남으면 결과는 (뒤따르는 구분자와 함께) (build-path 'same)과 같을 수 있습니다.

use-filesystem?#f일 때 path 인자는 어떤 플랫폼의 경로일 수 있고, 결과 경로는 같은 플랫폼을 위한 것입니다.

use-filesystem?가 참이면 파일시스템이 접근될 수 있지만, 소스나 단순화된 경로가 존재하지 않는 경로일 수 있습니다. 링크의 사이클 때문에 path를 단순화할 수 없으면 exn:fail:filesystem 예외가 일어납니다(하지만 성공적으로 단순화된 경로는 사이클이 단순화를 방해하지 않았다면 여전히 링크의 사이클을 포함할 수 있습니다).

경로 단순화에 대한 자세한 정보는 "Unix and Mac OS Paths"와 "Windows Paths"를 참고하세요.

예시:

> (let ([p (string->some-system-path "tiny//in/my/head/../../../dancer" 'unix)])
    (simplify-path p #f))
#<path:tiny/dancer>
procedure
(normal-case-path path) → path-for-some-system?
  path : (or/c path-string? path-for-some-system?)

"정규화된(normalized)" 대소문자 문자를 가진 path를 반환합니다. Unix와 Mac OS 경로의 경우, 이 플랫폼들의 파일시스템은 대소문자를 구분할 수 있으므로, 이 프로시저는 항상 입력 경로를 반환합니다. Windows 경로의 경우, path\\?\로 시작하지 않으면, 결과 문자열은 현재 로케일에 기반해 소문자만 사용합니다. 추가로, Windows 경로에서 경로가 \\?\로 시작하지 않으면 모든 /\로 변환되고, 뒤따르는 공백과 .이 제거됩니다.

path 인자는 어떤 플랫폼의 경로일 수 있지만, 현재 플랫폼에서의 로케일 민감 디코딩과 변환이 경로의 플랫폼에서와 다를 수 있다는 점에 주의하세요.

이 프로시저는 파일시스템에 접근하지 않습니다.

procedure
(split-path path) →
  (or/c path-for-some-system? 'relative #f)
  (or/c path-for-some-system? 'up 'same)
  boolean?
  path : (or/c path-string? path-for-some-system?)

path를 더 작은 경로와 바로 앞의 디렉토리 또는 파일 이름으로 분해합니다. 세 가지 값이 반환됩니다:

  • base는 다음 중 하나입니다:
    • 경로,
    • path가 바로 앞의 상대 디렉토리 또는 파일 이름이면 'relative,
    • path가 루트 디렉토리이면 #f.
  • name은 다음 중 하나입니다:
    • 디렉토리-이름 경로,
    • 파일 이름,
    • path의 마지막 부분이 앞선 경로의 부모 디렉토리를 지정하면 'up(예: Unix의 ..),
    • path의 마지막 부분이 앞선 경로와 같은 디렉토리를 지정하면 'same(예: Unix의 .).
  • must-be-dir?path가 (예: 뒤따르는 구분자로) 명시적으로 디렉토리를 지정하면 #t, 그렇지 않으면 #f입니다. must-be-dir?name이 실제로 디렉토리인지 여부를 지정하는 것이 아니라, path가 구문상으로 디렉토리를 지정하는지 여부를 지정합니다.

path에 비해, (있다면) 중복 구분자가 결과 basename에서 제거됩니다. base#f이면 name'up이나 'same일 수 없습니다. path 인자는 어떤 플랫폼의 경로일 수 있고, 결과 경로들은 같은 플랫폼을 위한 것입니다.

이 프로시저는 파일시스템에 접근하지 않습니다.

경로 분할에 대한 자세한 정보는 "Unix and Mac OS Paths"와 "Windows Paths"를 참고하세요.

procedure
(explode-path path) → (listof (or/c path-for-some-system? 'up 'same))
  path : (or/c path-string? path-for-some-system?)

path를 구성하는 경로 요소들의 리스트를 반환합니다. pathsimple-form-path의 의미로 단순화되어 있으면, 결과는 항상 경로들의 리스트이고, 리스트의 첫 요소는 루트입니다.

explode-path 함수는 (중간 경로를 할당해야 하는 split-path를 사용하는 루프와 달리) path 길이에 비례하는 시간에 결과를 계산합니다.

procedure
(path-replace-extension path ext) → path-for-some-system?
  path : (or/c path-string? path-for-some-system?)
  ext : (or/c string? bytes?)

path와 같지만, 경로의 마지막 요소에 대한 확장자(확장자 구분자 포함)가 ext로 바뀐 경로를 반환합니다. path의 마지막 요소에 확장자가 없으면 ext가 경로에 추가됩니다.

확장자는 경로 요소의 시작에 있지 않은 . 뒤에, 경로 요소가 ".." 같은 디렉토리 표시가 아닌 한, 경로 요소 끝에 오는 임의의 수의 비-. 문자/바이트로 정의됩니다.

path 인자는 어떤 플랫폼의 경로일 수 있고, 결과는 같은 플랫폼을 위한 것입니다. path가 루트를 나타내면 exn:fail:contract 예외가 일어납니다. 주어진 ext는 보통 .로 시작하지만, 확장자 구분자로 시작할 필요는 없습니다.

예시:

> (path-replace-extension "x/y.ss" #".rkt")
#<path:x/y.rkt>
> (path-replace-extension "x/y.ss" #"")
#<path:x/y>
> (path-replace-extension "x/y" #".rkt")
#<path:x/y.rkt>
> (path-replace-extension "x/y.tar.gz" #".rkt")
#<path:x/y.tar.rkt>
> (path-replace-extension "x/.racketrc" #".rkt")
#<path:x/.racketrc.rkt>

base 패키지의 6.5.0.3 버전에서 추가됨.

procedure
(path-add-extension path ext [sep]) → path-for-some-system?
  path : (or/c path-string? path-for-some-system?)
  ext : (or/c string? bytes?)
  sep : (or/c string? bytes?) = #"_"

path-replace-extension과 비슷하지만, path의 기존 확장자는 확장자 앞의 .sep로 바꿔서 보존되고, 그런 다음 ext가 끝에 추가됩니다.

예시:

> (path-add-extension "x/y.ss" #".rkt")
#<path:x/y_ss.rkt>
> (path-add-extension "x/y" #".rkt")
#<path:x/y.rkt>
> (path-add-extension "x/y.tar.gz" #".rkt")
#<path:x/y.tar_gz.rkt>
> (path-add-extension "x/y.tar.gz" #".rkt" #".")
#<path:x/y.tar.gz.rkt>
> (path-add-extension "x/.racketrc" #".rkt")
#<path:x/.racketrc.rkt>

base 패키지의 6.5.0.3 버전에서 추가됨. 6.8.0.2 버전에서 변경됨: sep 선택적 인자가 추가되었습니다.

procedure
(path-replace-suffix path ext) → path-for-some-system?
  path : (or/c path-string? path-for-some-system?)
  ext : (or/c string? bytes?)

참고: 이 함수는 더 이상 사용되지 않습니다(deprecated). 대신 path-replace-extension을 사용하세요.

path-replace-extension과 같지만, 경로 요소의 앞에 오는 .를 확장자 구분자로 취급합니다.

procedure
(path-add-suffix path ext) → path-for-some-system?
  path : (or/c path-string? path-for-some-system?)
  ext : (or/c string? bytes?)

참고: 이 함수는 더 이상 사용되지 않습니다(deprecated). 대신 path-add-extension을 사용하세요.

path-add-extension과 같지만, 경로 요소의 앞에 오는 .를 확장자 구분자로 취급합니다.

procedure
(reroot-path path root-path) → path-for-some-system?
  path : (or/c path-string? path-for-some-system?)
  root-path : (or/c path-string? path-for-some-system?)

path의 완전한 형태에 기반해 root-path를 확장하는 경로를 만듭니다.

path가 아직 완전하지 않으면 path->complete-path를 통해 완료되는데, 그 경우 path는 현재 플랫폼의 경로여야 합니다. path 인자는 또한 normal-case-path를 통해 정화되고 대소문자가 정규화됩니다. 그런 다음 pathroot-path에 추가됩니다. Windows 경로의 경우, 루트 문자 드라이브는 문자 경로 요소가 되고, 루트 UNC 경로는 경로 요소로 "UNC"가 접두어가 되며 기계와 볼륨 이름이 경로 요소가 됩니다.

예시:

> (reroot-path (bytes->path #"/home/caprica/baltar" 'unix)
               (bytes->path #"/earth" 'unix))
#<path:/earth/home/caprica/baltar>

> (reroot-path (bytes->path #"c:\\usr\\adama" 'windows)
               (bytes->path #"\\\\earth\\africa\\" 'windows))
#<windows-path:\\earth\africa\c\usr\adama>

> (reroot-path (bytes->path #"\\\\galactica\\cac\\adama" 'windows)
               (bytes->path #"s:\\earth\\africa\\" 'windows))
#<windows-path:s:\earth\africa\UNC\galactica\cac\adama>

더 알아보기