☰

경로에 있는 모든 "/./" 발생(겹칠 수 있음)을 "/"로 바꾸는 것이 "안전"합니까?

tag-icon • tag-icon shell path
경로에 있는 모든 "/./" 발생(겹칠 수 있음)을 "/"로 바꾸는 것이 "안전"합니까?

/.//POSIX 호환 시스템에서 원래 경로와 동일한 대상으로 연결되도록 보장되는 교체된 경로(겹칠 수 있음)가 있습니까 ?

예:

#!/bin/bash

shopt -s extglob

some_command -- "${@//\/+(.\/)//}"

고쳐 쓰다:

의견을 고려하면 동일하지 않으므로 질문을 업데이트하겠습니다.

POSIX 호환 시스템에서 원래 경로와 동일한 대상으로 연결되도록 보장되는 /././방식으로 나타나는(겹칠 수 있음) 경로가 대체되었습니까 ?/./

답변1

불행하게도 "POSIX 호환 시스템"은 현실 세계에서는 다소 모호합니다. POSIX는 표준의 다양한 부분과 하위 섹션을 통해 명령 세트, 셸, 파일 시스템, 시스템 호출, 스레딩 인터페이스 등의 일부를 다룹니다. 많은 시스템이 POSIX와 호환되지만 확장 기능이 있거나 POSIX 표준 부분이 호환되지 않거나 확장된 부분과 공존합니다.

//경우에 따라 일부 시스템에서는 문자열의 시작 부분이 특별하게 처리될 수 있습니다.

나머지 문자열은 POSIX 시스템 또는 POSIX 호환 하위 시스템과 인터페이스하는 시스템에서 대체하거나 동일해야 /././합니다 /./. /또한 대부분의 경우 //문자열의 시작이나 여러 개의 연속된 슬래시를 제외한 모든 항목은 just 로 축소될 수 있습니다 /.

그러나 어떤 것들은 여전히 ​​당신을 넘어뜨릴 수 있습니다. 쉘과 FS는 /foo//bar이들을 동일하게 취급 할 수 있지만 /foo/bar파일 시스템 외부의 파일을 가리키는 웹 서버와 같은 것은 URL 측에서 파일을 동일한 방식으로 취급하지 않을 수 있으며 그 앞의 웹 캐시는 그렇지 않을 수 있습니다. 이는 URL에서 FS의 파일로 매핑하는 것이 간단해 보일 수 있지만 하나의 표준과 다른 표준이 순진하게 추측한 대로 반드시 정확하게 매핑되지 않는 곳이 있기 때문입니다. FS 앞의 다른 네트워크 계층은 유사한 극단적인 경우를 일으킬 수 있습니다.

/foo//bar특히, 우리 팀이 우리 구성에서 동일한 백엔드 파일이 처음에 캐시되지만 두 개의 서로 다른 캐시 TTL이 있는 두 개의 서로 다른 캐시 개체에 사용된다는 사실을 발견했을 때 정적 파일을 제공하는 Apache 서버의 문제가 생각났습니다 /foo/bar. 더 일찍 캐싱합니다. Varnish 구성을 정식 형식으로 다시 작성하면 이 문제가 해결됩니다.

답변2

존재하다경로명 확인slashPOSIX 2018에서는 두 문자로 시작하는 경로의 특별한 경우가 설명됩니다.

slash경로 이름이 연속된 두 문자 로 시작하는 경우첫 번째 구성요소두 개 이상의 선행 문자는 단일 문자로 처리되어야 하지만 후속 선행 slash문자는 구현에 정의된 방식으로 해석될 수 있습니다.slashslash

.그런 다음 경로에 a를 정의합니다.

특수 파일 이름은 dot이전 파일이 지정한 디렉토리를 참조해야 합니다.

POSIX 호환 시스템에서는 다음과 같은 결론을 내릴 수 있습니다.~해야 한다모든 겹침 발생을 경로의 /./단일 겹침으로 바꿀 수 있습니다.///./첫 번째로 시작하는 것을 제외하고 /./는 교체할 수 없습니다..

/././또한 이러한 시스템에서는 겹침을 단일로 교체하면 /./예외 없이 작동합니다.

관련 정보