디렉토리 경로 변수는 후행 슬래시로 끝나야합니까?

디렉토리 경로 변수는 후행 슬래시로 끝나야합니까?

---

디렉토리 경로를 변수 또는 상수로 정의 할 때 후행 슬래시로 끝나야합니까? 대회는 무엇입니까?

pwd유닉스에서는 후행 슬래시없이 현재 디렉토리를 표시하고 탭 완성 cd /var/www/apps/에는 후행 슬래시 가 포함되어 확실하지 않습니다.

---

예를 들어 파일 저장을위한 디렉토리를 정의 할 때 후행 슬래시를 포함하지 않습니다. 나는 그것을 다음과 같이 사용할 것이기 때문입니다.

$store_file = "$store_path/$file_id";

디렉토리 경로를 보유해야하는 변수를 사용하기 전에 항상 후행 슬래시를 추가합니다. 후행 슬래시가 포함되어 있는지 궁금해하는 것보다 항상 하나를 추가하는 것이 좋습니다.

---

다음과 같은 이유로 후행 슬래시를 사용합니다.

1. "슬래시로 끝나면 디렉토리이고, 그렇지 않으면 파일입니다." 기억하기 쉬운 규칙입니다.

2. 적어도 내가 일반적으로 사용하는 OS에서는 슬래시를 두 배로 늘리면 문제가 발생하지 않지만 슬래시를 생략하면 큰 문제가 발생합니다. 따라서 변수에 슬래시를 넣고 사용할 때 "$ path / $ file"을 사용하는 것이 가장 안전합니다.

---

예, 다음과 같이해야합니다.

경로 이름 + 파일 이름 = 완전한 파일 위치.

따라서 마지막 디렉토리와 파일 이름 사이의 슬래시는 경로 이름의 끝 또는 파일 이름의 시작에 있어야합니다. 파일 이름 앞에 /를 붙이는 것은 파일을 열기 만하면 (즉, 현재 작업 디렉토리에 정규화되지 않은 파일 이름이 있다고 가정하는 경우)이를 고려해야 함을 의미합니다.

---

디렉토리 경로를 저장하거나 API에서 반환 할 때마다 후행 슬래시를 유지하는 규칙을 고수하려고합니다. 이것은 '파일인가 디렉토리인가'라는 모호함 전체를 피합니다.

부록 :
이것은 후행 슬래시 또는 그 부재를 허용 할 수있는 방법을 사용하는 대신 사용할 수 없습니다. 이 규칙을 사용하더라도 나는 여전히 항상 Path.Combine(...)비슷한 방법을 사용 합니다.

---

나는 이것이 오래된 스레드라는 것을 알고 있지만 내가하는 일을 공유 할 것이라고 생각했습니다. 가능하면 일반적으로 둘 다 허용하고 다음과 같이 수행합니다 (PHP 인 경우).

$fullPath = rtrim($directory, '/') . '/filename.txt');

이렇게하면 디렉토리가 구성 파일에 정의되어있는 경우 다음 사람이 변경할 사람이 후행 슬래시를 포함하는지 여부는 중요하지 않습니다.

---

PHP에서는 dirname (__ FILE __) 함수가 끝에 슬래시없이 디렉토리 이름을 반환하기 때문에. 나는 그 관습을 고수하는 경향이 있습니다.

그렇지 않으면 디렉토리 이름 끝에 슬래시를 사용하면 dirname (..)이 작동하는 방식과 충돌하고 디렉토리 이름이 dirname (..)에서 왔는지 알 수 없기 때문에 두 가지 경우를 처리해야합니다. ) 함수 또는 후행 슬래시로 정의 된 상수.

결론 : dirname (..)은 사용하지 않으므로 후행 슬래시를 사용하지 마십시오.

// PHP Example
dirname(__FILE__); // returns c:\my\directory without a trailing slash, so stick to it!

다른 언어의 경우 경로 이름을 추출하는 함수를 확인하고 후행 슬래시를 사용하는지 여부를 확인한 다음 언어 규칙을 준수하십시오.

---

당신의 결정이 파일에 어떤 의미가 있는지 생각 해봐야 할 것입니다. 디렉토리 이름 끝에 슬래시를 포함하지 않으면 파일 이름 의 시작 부분에 추가해야합니다 .

이제 어떤 이유로 문자열을 연결할 때 파일로 이어지는 경로가 누락되면 /filename파일이 아니라 루트 디렉토리의 절대 경로 (해당 컨텍스트에있을 수있는 모든 위치) 와 같은 것으로 끝납니다 .

그래서 슬래시로 내 경로를 끝내고 파일을 파일로 유지합니다.

---

나는 이것이 10 년이라는 것을 알고있다. 그러나 나는 나의 매우 독단적 인 $ 0.02를 던지고 싶었다.

아니, 절대 아니야.

우리는 유닉스 시스템에 대해 이야기하고 있습니다. 디렉토리 자체와 관련하여 다른 노드와 마찬가지로 노드입니다. 디렉토리를 참조 할 때, 어느 이름에 이스케이프 슬래시가 없어야합니다 (참조 : dirname, pwd, ~, echo $HOME, echo $PATH,의 출력 ls등).

디렉토리의 내용을 언급 할 때, 다음 당신은 슬래시가 필요합니다. 즉, (FTR, 나는 거의 항상 후자를하는데 ... 글쎄, 게으른) ls /home/karl/보다 더 적절 ls /home/karl합니다.

디렉토리를 포함하는 변수를 사용하여 파일에 대한 전체 경로를 만들 때 항상 슬래시 (예 :)를 포함해야합니다 cp ${HOME}/test ${OTHER_DIR}/.

되는 예상 디렉토리가 슬래시로 끝나지있다. 디렉토리가 슬래시로 끝날 것이라는 예상은 잘못되었습니다. 따라서 *_DIR변수 값 끝에 슬래시를 추가하면 기대치를 뒤집을 수 있습니다.

그것이 틀렸다고해서 도구 / 패키지 / 라이브러리가 절대 그렇게하지 않는다는 의미는 아닙니다. 그런 것들이 존재하지 않아야 할 때 후행 슬래시를 추가하는 것은 매우 흔한 일입니다. 따라서 Bevan 과 Paul F가 모두 제안했듯이 타사 도구를 사용할 때는 디렉터리 이름에있을 수있는 후행 슬래시를 제거하는 것이 가장 좋습니다.

Unix Inode

inode (인덱스 노드)는 파일 또는 디렉토리와 같은 파일 시스템 객체를 설명하는 Unix 스타일 파일 시스템의 데이터 구조입니다.

-https : //en.wikipedia.org/wiki/Inode

파일 시스템 계층 표준

유닉스 파일 시스템 (Filesystem Hierarchy Standard에, AKA FHS)에 대한 기준이 명확 후행 슬래시를 가진 것으로 디렉토리가 생각하지 않는 것을 보여 아니라 디렉토리 내용이 슬래시로 시작 (이 유일한 예외는 /우리가 참조하지 않기 때문에 빈 문자열을 사용하여 파일 시스템 루트 ... 어쨌든 파일을 생성해서는 안됩니다.)

-http: //www.pathname.com/fhs/pub/fhs-2.3.html

-https : //en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

---

파일을 추가 / 검색하기 위해 해당 디렉토리를 사용할 가능성이 높기 때문에 후행 슬래시를 추가하는 경향이 있습니다.

웹 참조와 관련하여 실제로 성능을 향상시킬 수 있습니다.

http://www.netmechanic.com/news/vol4/load_no11.htm

---

Yes, there are lots of filesystems that support files without any extensions, so always add the trailing slash to avoid any problems.

---

I've never seen a firm convention either way.

Pretty sure, though, that whatever you settle upon, someone else will be 100% sure it should be the other way. So, best idea is to tolerate things being set either way.

In the .NET world, Path.Combine() gives you a way to handle this - there are equivalents in other environments, from cmd files on up.

참고URL : https://stackoverflow.com/questions/980255/should-a-directory-path-variable-end-with-a-trailing-slash