나 하나 작업 중이야경로의 수학적 설명(파일 경로와 비슷하지만 더 추상적이고 일반적인 경우도 있음)
정의하기 가장 까다로운 것 중 하나는 ..(링크된 게시물의 ψ) 동작, 특히 심볼릭 링크와 상호 작용하는 방식입니다.
POSIX 규칙을 올바르게 이해하고 있는지 확인하고 싶습니다.
POSIX 4.14설명하다
프로세스가 기존 디렉터리 항목의 경로 이름을 확인할 때 전체 경로 이름은 다음과 같이 확인되어야 합니다. 프로세스가 경로 이름을 확인한 후 즉시 생성된 디렉터리 항목의 경로 이름을 확인하는 경우 마지막 구성 요소의 경로 접두사의 모든 구성 요소가 확인되면 경로 이름 확인이 종료됩니다. 그런 다음 프로세스는 최종 구성 요소를 생성하는 역할을 담당합니다. ... 경로 이름의 각 파일 이름은 이전 파일에서 지정한 디렉터리에 있습니다(예를 들어, 경로 이름 조각 a/b에서 파일 b는 디렉터리 a에 있습니다). ...경로 이름 확인 중에 기호 링크가 발견되면...시스템은 나머지 경로 이름(있는 경우) 앞에 기호 링크의 내용을 추가해야 합니다. 확인된 경로 이름은 방금 생성된 경로 이름의 확인이어야 합니다. 생성된 경로 이름이 로 시작하지 않으면 경로 이름의 첫 번째 파일 이름 선행 항목이 기호 링크를 포함하는 디렉터리로 처리됩니다. 특수 파일 이름 점은 이전 항목에서 지정한 디렉터리를 참조해야 합니다. 특수 파일 이름 dot-dot은 이전 파일의 상위 디렉터리를 참조해야 합니다. 특별한 경우로, 루트 디렉터리에서 점-점은 루트 디렉터리 자체를 참조할 수 있습니다. ..
그래서 내 이해는..POSIX에서는 상위 디렉터리로 연결되기 전에 심볼릭 링크를 확장해야 한다고 말합니다.
맞습니까?
따라서 정규화된 경로의 경우 POSIX 호환 방식은 다음과 같습니다.
realpath -P
이를 위해서는 모든 디렉터리가 존재해야 하며(최종 파일 구성 요소는 아님) 왼쪽에서 오른쪽으로 확장하여 심볼릭 링크(한 번 발생하면)를 확인한 다음 적용합니다...
즉, 경로를 처리하는 모든 단계에서 파일 시스템을 읽어야 합니다.
이를 다음 동작과 대조할 수 있습니다.node.jsPath.normalize(또는 심지어 Path.posix.normalize) - 많은 프로그래밍 언어에서는 이것이 상당히 정상적인 것이라고 생각합니다.파이썬2그리고삼 os.path유사합니다). 이는 realpath -s -m,즉, 일부 디렉토리가 simlink일 수도 있고 존재하지 않을 수도 있다는 점을 완전히 무시합니다.
파일 시스템을 전혀 건드릴 필요가 없기 때문에 좋습니다.
이런 방식으로 정규화된 경로를 가져와서 파일 시스템에 닿는 함수(예: fs.readFile)에 제공하면 정규화된 경로를 사용하는 것과 동일합니다 realpath -L."symlink 전에 해결 .."
또한 Bash는 플래그를 지정하지 않는 한 cd인수를 처리한 것처럼 동작합니다.realpath -L-P
POSIX 사양과 realpath많은(대부분?) 프로그래밍 언어 경로 라이브러리와의 관계를 올바르게 이해하고 있습니까?
realpath보너스 질문: -P, POSIX와 호환되는 정식 구현을 갖춘 프로그래밍 언어/라이브러리(이와 같은 쉘 유틸리티를 사용하는 것 제외)의 예를 갖고 있는 사람이 있습니까 ? (파이썬 3 나는 믿는다pathlib.Path.resolve맞다. 상대 경로를 절대 경로로 변환하기도 합니다. )
답변1
POSIX 사양에 대한 귀하의 이해가 정확합니다. 이는 디렉토리가 이름이 있는 다른 노드를 가리키는 파일 시스템의 노드일 뿐이라는 관점에서 볼 때 의미가 있습니다. .의 특수 노드는 ..경로(문자열)가 아닌 리터럴 노드를 가리킵니다.
대부분의 프로그래밍 라이브러리 경로 문자열 조작 함수는 파일 시스템의 실제 내용과 아무 관련이 없으므로 단순히 문자열 조작으로 정규화해야 합니다. 이것의 장점은 존재하지 않거나 읽기 권한이 없는 경로를 정규화할 수 있다는 것입니다.
POSIX 방식으로 경로를 정규화하려면 ..상대 경로가 아닌 절대 경로를 사용하여 정규화해야 합니다. 그렇지 않으면 의미가 없습니다. 기호 링크 경로는 상대 경로가 더 이상 의미가 없거나 도달하려면 다른 경로가 필요한 파일 시스템의 완전히 다른 부분을 가리킬 수 있습니다 ... 원하는 경우 readlink 및 일부 규칙을 사용하여 상대 경로를 사용할 수 있는지 확인할 수 있지만 경로 라이브러리에는 이 문제를 해결할 수 있는 기능이 없다고 생각합니다.
답변2
.Unix 에서 .. 상위 디렉터리에 속하는 실제 파일(파일 또는 디렉터리)을 나타내는 실제 디렉터리 항목입니다.
..경로의 마지막 세그먼트를 제거하는 데 사용되는 경로 구문 분석 키워드가 아닙니다. 를 구문 분석하려면 ..먼저 해당 항목이 포함된 디렉터리를 구문 분석해야 합니다. Nodejs가 잘못하고 있습니다.
$ mkdir -p /tmp/foo/bar/baz
$ ln -s /tmp/foo/bar/baz /tmp/symlink
$ realpath /tmp/symlink/..
/tmp/foo/bar
$ node -e 'console.log(path.normalize("/tmp/symlink/.."))'
/tmp
(이 항목은 디렉토리가 생성될 때 항상 생성되며 현재 디렉토리와 상위 디렉토리에 대한 하드 링크로 사용됩니다. 이는 드문 예입니다.디렉토리 하드 링크, 시스템은 일반적으로 일반 사용자가 디렉토리 하드 링크를 생성하는 것을 허용하지 않기 때문입니다.
ls -ld이것이 하위 디렉토리를 생성할 때마다 디렉토리의 하드 링크 수가 증가하는 이유이며, 디렉토리가 3(이름, . 및 _name/..)의 하드 링크 수로 시작하는 이유입니다. 하위 디렉터리는 ..현재 디렉터리에 대한 하드 링크이므로 하드 링크 수가 늘어납니다. )