쉘 스크립트에서 경로 변수 끝에 슬래시를 사용해야합니까? [닫은]


11

오늘 내 쉘 스크립트를 작성할 때.

질문이 갑자기 내 마음에 온다.

이후 cd /target_dircd /target_dir/두 작품.
쉘 스크립트에서 경로 변수 끝에 슬래시를 추가해야합니까?
LOG_PATH=/data/nginx/logsLOG_PATH=/data/nginx/logs/.

Google에서 총 검색을했지만 이에 대한 토론을 찾지 못했습니다. 너무 기본적입니까?

지금은 어떤 스타일을 선택할지 결정하기가 정말 어렵습니다.
그러나 LOG_PATH=/target_dir/스타일을 조금 더 선호했습니다 .
bash로 자동 완성을 할 때 슬래시로 결과가 나옵니다.

이것에 대한 당신의 의견은 무엇입니까?



규칙이 없습니다. 두 코딩 스타일에는 몇 가지 장점과 단점이 있습니다.
andcoz 2016 년

답변:


9

POSIX에 따르면 :

경로명의 정의 :

파일을 식별하는 데 사용되는 문자열입니다. 이 옵션 시작이 <슬래시> 로 구분 된 0 개 이상의 파일 이름 뒤에 문자, <슬래시> 문자. 경로 이름에는 선택적으로 하나 이상의 후행 <슬래시> 문자가 포함될 수 있습니다 . 연속적인 <슬래시> 문자는 정확히 두 개의 선행 <슬래시> 문자 인 경우를 제외하고 하나의 <슬래시> 와 동일한 것으로 간주됩니다 .


@ 흥미롭게도, bash 프롬프트에서 이름을 바꾸어 CD ///다른 이름을 표시 pwd할 수 있으며 다른 경로를 사용 하지만 내용은 동일합니다! 왜?
Zen


1
때문에 bash트랙 문자열로 매우 순진 방법으로 현재 디렉토리. 단지 경로에서 경험적으로 추가하고 제거하며 실제 파일 시스템에 연결되지 않습니다. 한 가지 결과는 심볼릭 링크로 들어가서 같은 방식으로 돌아갈 수 있다는 것입니다 (bash가 너무 많이 결정하지 않고 다시 초기화 한 경우). 다른 하나는 당신이 설명하는 것입니다. 현재 디렉토리의 쉘 추적에 의존해서는 안되며 신뢰할 수 없습니다.
오리온


6

안전한면에 있도록 슬래시를 포함하십시오. 경로를 연결할 때 여러 번의 슬래시가 발생할 수 있지만 최소한 문제는 피해야합니다.

몇 가지 예 : rsync후행 슬래시가 포함 된 경우 경로를 다르게 취급합니다 ( 다른 서브 디렉토리를 작성하는 대신 해당 디렉토리를 동기화 ). 디렉토리에 대한 심볼릭 링크는 슬래시가없는 경우 예기치 않은 방식으로 작동합니다. 최소한 셸 완성이 혼란스러워집니다. 호출 한 명령 / 스크립트가 특정 동작에 대한 슬래시를 확인하는 데 의존하는지 여부는 알 수 없습니다. 덮어 쓰는 것을 막을 수도 있습니다. 예를 들어,이라는 파일이 foo있지만 실수로 디렉토리라고 생각하고 그 안에 무언가를 옮기고 싶다면 mv bar foo파일 (데이터 손실, 재앙 가능성)을 덮어 쓰지만 mv bar foo/불평하고 아무것도하지 않습니다.

결론적으로, 그것은 대부분의 경우 중요하지 않지만 슬래시를 사용하여 자신을 보호하고 인간 독자에게 스크립트에서하려는 일을보다 분명하게 만들어야합니다. 일반 관찰자는 변수가 슬래시로 끝나는 디렉토리를 참조하는지 즉시 확인하고 수정해야 할 경우 올바르게 사용합니다.


2

아닙니다. 불필요한 슬래시 ( /) 가 추가 됩니다.

java bin디렉토리를 PATH변수 로 내보내고 싶다고 가정 해보십시오 .

export PATH=$PATH:/opt/jre1.7.0_45/bin/

이제 확인 해봐

user@host:~$ which java
/opt/jre1.7.0_45/bin//java

/자바 앞에 여분의 슬래시 ( )를 주목 하지만 다행히도 그러한 경우에만 작동합니다.


나는이 링크에서 저자가 우리가 슬래시를 추가해야한다고 생각하는 31 투표 답변을 보았다. 혼란 스러워요. stackoverflow.com/questions/980255/…
Zen

@ 젠, 네, 확인했습니다. 귀하의 질문에 대한 첫 번째 의견이었습니다. 감사.
Arnab

6
둘보다 슬래시가 더 좋습니다. 이것은 추악하지만 안전합니다 ... 다른 옵션은 훨씬 더 나쁘고 위험 할 수 있습니다.
오리온
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.