.png)
GCC 크로스 컴파일러의 특정 버전을 구축하기 위한 스크립트가 있습니다. 스크립트 전체에는 반복되는 경로 구분 기호( /xxx/foo//bar/yyy) 및 중간에 있는 "this" 디렉터리( ) 와 같이 정식 형식이 아닌 경로가 많이 있습니다 /xxx/foo/./bar/yyy.
나는 그것들을 모두 정규화할 계획이지만, 스크립트가 위생화되지 않은 경우를 넘어 양식이 중요한지 궁금합니다. 방금 언급한 형식 외에도 경로에 "up 디렉토리"를 포함하는 것이 특정 경우(예: " 대신 /xxx/foo/../bar/yyy" /xxx/bar/yyy)에도 중요한지 궁금합니다. 예를 들어, 나는 /xxx/foo/.//bar/yyy.
내가 생각할 수 있는 유일한 상황은 링크가 관련된 경우입니다. 양식이 다르게 동작할 수 있다고 상상할 수 있지만 ..위의 다른 두 가지 양식은 어떻습니까?
어쩌면 이런 방식으로 경로를 구축하는 플랫폼별 이유도 있을 수 있습니다..?
답변1
/./항상 충돌이 발생할 수 있어야 합니다 /.
//일반적으로 접을 수 있어야 하지만 구성 스크립트에서 이를 확인하는 것을 본 적이 있으므로 다른 시스템이 있을 수 있다고 가정합니다. 확인해 보세요. 하지만 아마 괜찮을 것입니다.
/../이전 디렉토리가 심볼릭 링크가 아닌 경우에만 작동합니다(또는 하드 링크가 아니라고 생각합니다). 상위 디렉토리에 대한 하드 링크 이므로 ..사용한 텍스트 경로의 분기가 아닌 해당 분기로 이동합니다. (쉘이 cds의 심볼릭 링크를 해결하지 않도록 설정되어 있을 수 있으며, 이 경우 심볼릭 링크가 있는 디렉터리로 이동합니다. 그러나 이 동작은 거의 전적으로 cd이 옵션이 설정된 쉘로 제한됩니다.)
을 사용하면 readlink -f "$path"이 모든 상황이 적절하게 해결될 것이라고 믿습니다.