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

85

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

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

unix  file  variables  path 
— Meleyal
소스

답변:

23

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

$store_file = "$store_path/$file_id";

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

— 요한 소더버그
소스
29
후행 슬래시가 없다는 것은 $ store_path의 경로가 파일인지 디렉토리인지 명확하지 않다는 것을 의미합니다. "/ tmp / store_data"는 파일 또는 디렉토리입니까?
— Darwin
4
PHP의 realpath () 함수 와 같은 것을 사용 하면 후행 슬래시가 인쇄되지 않습니다. 시스템과 도구에 따라 규칙이 결정될 수 있습니다.
— jmbertucci
10
일반적으로 슬래시가 여러 개 있으면 하나의 슬래시로 해석됩니다. 그래서 당신은 같은 것을 가질 수도 '///' + $root + '//' + $file + '/'있고 그것은 중요하지 않을 것입니다. 후행 슬래시를 갖는 경로가 파일 또는 같은 경로에 추가 할 좋을 것이다 디렉토리인지 여부를 식별 할 수있는 좋은 방법이지만 '/' + $root보다는 $root + '/'당신이 경로에 추가되고있는 점은 긍정적이 될 수 없기 때문에이 슬래시있다 그러나 대부분의 환경에서 여러 개의 슬래시가 단일 슬래시로 해석된다는 것을 비교적 안심할 수 있습니다.
— Xtrinity
3
@MatthewSlyman, 내 요점은 모두가 이것이 /tmp/store_data/디렉토리가 될 것으로 기대 하는 반면, traling 슬래시가없는 동일한 경로가 무엇인지 명확하지 않다는 것입니다/tmp/store_data
— Darwin
6
문제는 변수가 존재하지 않으면 비어있는 것과 같으며 a로 rm -rf $foo/$bar끝날 수 있습니다.rm -rf /
— 12431234123412341234123
100

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

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

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

— 데이브 셰로만
소스
9
디렉토리 경로는 뒤에 슬래시가있는 경우에만 파일 경로와 구별 할 수 있습니다.
— Darwin
4
경로가 이중 슬래시로 시작하지 않는 한 다중 슬래시는 하나의 슬래시와 같습니다. unix.stackexchange.com/questions/1910/…
— jdh8
4
추가적으로 vaariable 끝에 슬래시를 추가하면 "$ path / $ file"대신 "$ path $ file"을 사용할 수 있습니다. 이는 빈 $ path-현재 작업 디렉토리를 의미합니다. 그러나 슬래시 대신 백 슬래시를 사용하지 마십시오.
— fantastory
파일 기술자도 유용하다
— 프란체스코 Gualazzi
@ jdh8 경로가 이중 슬래시로 시작하더라도 여전히 하나의 슬래시와 동일해야합니다. 이것은 구현에서 구현으로 변경 될 수 있습니다. 유닉스 표준에 A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner, although more than two leading slashes shall be treated as a single slash.따르면 대부분의 경우 이중 슬래시는 일반적으로 일반적인 구현에서 단일 슬래시로 해석됩니다.
— Xtrinity
12

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

아니, 절대 아니야.

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

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

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

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

탭 완성과 관련하여 여기서 예상 되는 것은 해당 디렉토리 로 이동 하는 것 입니다. 따라서 탭 완성으로 제공되는 지원은 해당 디렉토리로 이동하여 내용에 따라 다음 선택을 할 수 있도록하는 것입니다.

(댓글 참조 : Filepath Misconceptions , Wikipedia Talk:Path_(computing)페이지에서. 감사합니다, john cj )

그것이 틀렸다고해서 도구 / 패키지 / 라이브러리가 절대 그렇게하지 않는다는 것을 의미하지는 않는다는 점은 주목할 가치가 있습니다. 그러한 것들이 존재하지 않아야 할 때 후행 슬래시를 추가하는 것은 매우 흔한 일입니다. 따라서 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

— 칼 윌버
소스
훌륭한 대답입니다. 나는이 접근법을 사용하는 경향이 있었지만 그 이유에 대해 완전히 완전하지는 않았습니다. 이것은 그것을 못 박는 유일한 대답입니다.
— wardw
4
/패턴을 깨는 것은 뿌리 입니다. 그리고 여기에서 (재귀 적으로) 추론을 시작한다면 (여기 답변에서 입증 된 바와 같이) 다양한 관행의 중심에있을 수있는 모순에 도달 할 수 있습니다. 그러나 이것을 예외로 받아들이면 다른 모든 것이 일치합니다.
— wardw
내가 참조. dirname으로 약간 놀았습니다. 경로에 디렉토리를 명시 적으로 저장하려면 "/."로 경로를 끝내십시오. 여기서 점은 현재 디렉토리를 나타냅니다.
— TamusJRoyce 2019
당신은 것입니다 결코 기호가있는 끝없는 /., 이것은 단지 끔찍한 생각입니다; 예상치 못한 문제로 이어지는 매우 특이한 콘텐츠를 삽입하는 것 외에도 어리석은 것처럼 보입니다.
— Karl Wilbur
2
@wardw 루트 디렉토리는 이름이 빈 문자열 인 것으로 생각할 수 있습니다. 반면 "/"는 슬래시가 뒤 따르는 빈 문자열이며 "루트 디렉토리의 내용"을 의미합니다.
— bobpaul
9

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

경로 이름 + 파일 이름 = 정규화 된 파일 위치.

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

— PaulJWilliams
소스
5
.. 그리고 그것을 고려하지 않는 것은 당신이 실수로 /를 엉망으로 만들고 있다는 것을 의미하며, 그런 식으로 광기가 놓여 있습니다
— JustJeff
5

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

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

— jerryjvl
소스
파이썬 :os.path.join(dir, subdir_or_file)
— IceArdor
5

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

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

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

— DanMan
소스
1
여기서 대안은 파일 이름을 ./filename. 그러나 일반적으로 경로를 연결하여 올바르게 수행하고 어느 쪽이든 가정하지 않는 것은 코드의 책임이어야합니다.
— wardw
4

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

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

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

— 폴 F
소스
4

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

그렇지 않으면 디렉토리 이름 끝에 슬래시를 사용하면 dirname (..)이 작동하는 방식과 충돌하고 디렉토리 이름이 dirname (.. ) 함수 또는 후행 슬래시로 정의 된 내용.

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

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

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

— 바질 무사
소스
2
예외 : dirname ( '/ test') = '/'— 빈 문자열을 반환하는 대신 dirname은이 경우 단일 슬래시를 반환합니다! 여기 에서 참고를 참조 하십시오 .
— Matthew Slyman
2

예, 확장자가없는 파일을 지원하는 많은 파일 시스템이 있으므로 문제가 발생하지 않도록 항상 후행 슬래시를 추가하십시오.

— maxp
소스
1

어느 쪽이든 확고한 대회를 본 적이 없습니다.

하지만 당신이 무엇에 정착하든 다른 사람은 그것이 반대가되어야한다고 100 % 확신 할 것입니다. 따라서 가장 좋은 아이디어는 어느 쪽이든 설정되는 것을 허용하는 것입니다.

.NET 세계에서 Path.Combine ()은이를 처리 할 수있는 방법을 제공합니다. cmd 파일부터 다른 환경에서도 동등한 기능이 있습니다.

— 베반
소스
1

나는 이것이 이론적으로나 실제적으로 올바른 대답이 다른 드문 경우 중 하나라고 생각합니다.

@Karl Wilbur의 대답은 이론적 의미에서 옳은 것 같습니다. 디렉토리 노드 자체에 대한 참조를 디렉토리의 내용과 구별 할 수 있어야하기 때문입니다.

그러나 실제로 나는 정답이 그 반대라고 주장 할 것입니다.

  • 가장 중요한 이유는 경로 가 폴더 인 반면 모호하다는 것을 확실하게 알 수 있기 때문입니다 . 아무도 이것이 폴더의 파일인지 알 수 없습니다. 사양은 가능한 한 항상 정확하고 모호하지 않아야합니다./home/FSObjectX//home/FSObjectX

  • 대부분의 경우 dir 노드 자체가 아니라 항상 폴더의 내용을 참조합니다.
    실제로 수행하는 드문 경우에는 선택적 후행 dir-separator를 제거하여 코드에서 쉽게 처리 할 수 ​​있습니다.

  • 이중 dir-separator를 사용한다고해서 아무런 해를 끼치 지 않습니다.
    이론 상으로는 "기회"로 코딩해서는 안되는 나쁜 주장이지만 실제로는 오류가 발생하고 아마도 후행 dir-sep을 사용하면 최종 사용자의 런타임 오류가 약간 줄어들 수 있습니다.

이 흥미로운 스레드를 읽어 보면 후행 dir-sep을 사용하는 데있어 어떤 단점도 발견하지 못했습니다. 단지 이론적 의미에서 잘못되었다는 것입니다. 아니면 내가 뭔가를 놓쳤습니까?

— 미스터 캘빈
소스
실제로는 후행 슬래시를 포함하지 않는 것이 적절한 기대임을 알 수 있습니다. 유능한 개발자가 작성한 모든 도구를 사용하십시오.
— Karl Wilbur
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.