파일 이름에 대문자를 사용하지 않는 것이 모범 사례로 간주됩니까?

사람들은 유닉스 파일 이름에 공백을 사용해서는 안된다고 말합니다. 파일 이름에 대문자를 사용하지 않는 좋은 이유가 있습니까 (예 : File_Name.txtvs. file_name.txt)? 아니면 이것은 개인적인 취향의 문제입니까?

사람들은 유닉스 파일 이름에 공백을두면 안된다고 말합니다.

사람들은 많은 것을 말합니다. 문제가 될 수있는 몇 가지 도구가 있지만, 현재로서는 공간이 소수의 독점 독점 OS 회사에 의해 확산되는 바이러스이기 때문에 피할 수 없기 때문에 현재로서는 그 수가 적습니다.

공백은 명령 행 등에서 파일 이름을 지정하기 어색합니다. 그게 다야. * nix 시스템에서 유일하게 금지 된 문자는 NUL (키보드 나 다른 사람이 아니라고 걱정하지 마십시오)이며 /경로 구분 기호이므로. ¹ 그 외에는 아무 것도 없습니다. 개별 경로 요소 (파일 이름)는 255 바이트 (확장 문자 세트를 사용하는 경우 가능한 합병증 )로 제한되며 4KiB 까지의 전체 경로입니다.

아니면 이것은 단지 개인적인 취향의 문제입니까?

나는 그것을 말할 것입니다. 대부분의 드의 당신은에 대문자 디렉토리의 회전을 만들 것 같다 $HOME( Downloads, Desktop, Documents- (가) D너무 그것에 대해 이상한 아무것도, 매우 인기가있다). 같은 그들의 수도, 매우 평범한 기존의 파일도있다 .Xclients하고 .Xauthority.

처음에 물건을 자본화하는 것의 가치는 사전 식으로 표시 될 때 최소한 많은 도구와 로케일에 따라 소문자보다 우선한다는 것입니다.

나는 낙타 사건 (일명 낙타 케이스)의 팬이며 파일 이름과 함께 사용합니다 /home/goldilocks/blueSuedeShoes. 분명히 개인적 취향의 문제이지만 아직 슬픔을 일으키지 않았습니다.

Java 클래스 파일은 기본적으로 대문자를 포함하는 경향이 있습니다. Java 클래스 이름이 그러하기 때문입니다. 물론, NetworkManager우리 중 일부는 선호하더라도 잊지 말자 .

^{1. 훨씬 더 POSIX 추천, 구분이있다 "휴대용 파일 이름 문자 집합" 하지 않는 공간을 포함 - 그러나이 포함되어 있습니까 대문자가! POSIX 는 또한 같은 문서의 다른 곳에서 "슬래시 문자 및 널 바이트"에 관한보다 일반적인 제한 사항을 지정합니다 . 이것은 오랜 전통 관행을 반영하거나 반영 합니다 .}

파일 이름에서 대문자를 피하는 한 가지 이유는 Unix에서 정렬 순서가 대소 문자를 구분하므로 대문자로 시작하는 파일이 순서대로 나타나지 않기 때문입니다. 이것이 Makefile보통 대문자를 사용하여 이름이 붙여 지는 이유 입니다. M스크롤을 건너 뛰거나 스크롤하지 않고 가장 먼저보고 싶은 파일 중 하나입니다 a-l.

이것은 파일 이름 측면에서 훨씬 나빠질 수 있다고 말했습니다.

• 공백을 사용하면 파일 이름을 올바르게 인용하지 않는 잘못 작성된 프로그램 및 스크립트가 손상됩니다.
• 기호가있는 파일 이름을 시작하는 -많은 프로그램이 명령 줄 옵션 대신에 파일 이름 (예 :로 표시됩니다으로 문제가 발생할 수 있습니다 rm -r라는 이름의 파일을 제거하지 않습니다 -r).
• 로 파일 이름을 시작하면 .많은 유틸리티와 셸 글 로빙에서 숨겨집니다 (예 : rm *와 같은 파일은 제거되지 않습니다 .config)
• 특수 문자와 같은 |<>*?인쇄 할 수없는 문자와 같은 특수 문자를 사용하는 newline것은 기술적으로 가능하지만 공백 문자와 유사한 스크립트 / 프로그램을 중단 할 수 있습니다. 차이점은 공백 문자가 자주 사용되므로 프로그래머가 프로그램을 테스트하는 경향이 있지만 덜 인기있는 문자는 테스트되지 않은 상태입니다.

Windows 환경과 인터페이스하려면 Windows가 모든 것을 소문자로 사용하므로 대문자를 사용하지 않아야합니다. 이것은 종종 다른 방향으로가는 문제입니다. 링크 는 Windows에서 Page_2.html찾을 수 page_2.html있지만 Unix에서는 실패합니다.

한도를 피하는 한 가지 이유는 bash탭 완성이 대소 문자를 구분하기 때문입니다 (적어도 기본적으로) . 이것은 기본 구성으로 끝날 때마다 여전히 저를 트립 bash합니다. 물론 다른 인기있는 쉘이 있지만 이것은 bash많은 OS에서 기본 로그인 쉘 이라는 사실과 결합 하여 기본값이 대소 문자를 구분하는 경우가 종종 있음을 의미합니다. 소문자로 된 파일 이름을 사용하면 여기서 단순화합니다.

NL_Derek은이 웜 캔을 열 었으나 올바르게 설명하지 않았으므로 다음과 같이 말할 것입니다.

그것은 사용 대문자로 OK,하지만 당신은 (같은 디렉토리에) 파일을 생성하지 않도록해야 다른 유일한 경우로 예를, File_Name.txt 하고 file_name.txt 있기 때문에,

• 어떻게 든 Windows 시스템에서 디렉토리를 사용할 수있게하면 두 파일 모두에 액세스 할 수 없습니다. 사용하는 이름에 관계없이 디렉토리에서 처음 나타나는 항목에만 액세스 할 수 있습니다. (단 FILENA~1.TXT, 이름과 이름을 FILENA~2.TXT 입력 dir /x하면 긴 이름과 함께 사용되는 짧은 이름을 볼 수 있습니다.)
• 파일 시스템이 실제로 Windows 파일 시스템 인 경우 (예 : Windows를 실행하는 NFS 서버에서 exFAT 또는 NTFS 파일 시스템에서 마운트 된 경우) 두 이름이 공존 할 수 없습니다. 예를 들어, 당신이 할 경우 와 , 당신의 출력을 포함하는 하나의 파일로 끝낼 수 있습니다 .cmd1 > foocmd2 > Foocmd2
• 마찬가지로, 파일을 Windows 시스템 으로 전송 한 경우 두 이름이 공존 할 수 없습니다. 예를 들어, 두 파일을 포함하는 아카이브 (예 : zip)를 작성하고 Windows 시스템에서 추출한 경우 두 번째 파일이 첫 번째 파일을 겹쳐 쓰게됩니다. FTP 또는 이와 유사한 것을 사용하여 Windows 상자로 전송 한 경우에도 마찬가지입니다.

기술적 인 이유와는 별도로, 나는 이것에 대한 실용적인 측면을 가지고 있습니다. grep -i를 사용하거나 -i를 찾는 것을 너무 좋아하지 않는 한 소문자를 고수하면보다 쉽게 ​​검색 할 수 있습니다. 때로는 스토리지 NYCDCPrimary에서와 같이 대소 문자를 사용해야하는 경우 낙타 케이스조차 혼란 스러울 수 있습니다. 따라서 storage_nyc_dc_primary와 같이 가독성을 높이기 위해 소문자를 붙이고 밑줄이나 하이픈을 사용하는 것이 가장 좋습니다.

나는 할 생각 이 가장 좋습니다 할 수도 사용하지 않는 파일 이름에 공백을.

어떤 사람들은 그들이 동의하지 않는다고 말하지만 그것은 내가 종교적 신념 이라고 부르는 문제입니다 : 토론하고 동의하기가 어렵습니다. 동의하지 않는 사람들은 대부분의 도구가 이제 수도와 공간 친화적으로 고정되어 있다고 말합니다. 그러나 옳지 만 이것은 문제가 아닙니다.

올바른 질문은 파일 이름에 대문자 와 공백 을 얼마나 사용해야하는지 입니다. Java로 프로그래밍 할 때를 제외 하고는이 질문에 대한 대답은 대부분 항상 입니다. 내 파일 이름에 대문자와 공백이 필요하지 않습니다 . 모든 공백은 밑줄 ( _) 또는 빼기 부호 ( -)로 대체되며 다른 종교와는 달리 낙타 경우 (일명 낙타 케이스)를 사용하지 않습니다.

많은 사람들이 저에게 헛소리라고 불렀습니다. 그들 중 일부는 여전히 그렇습니다. 그들 중 일부는 자본 / 공간 친화적이지 않은 도구로 넘어져서 제가 옳았다는 말을 들었습니다. 원하는대로 하십시오. 파일 이름에 대문자와 공백을 사용하면 잘못 작성된 도구를 사용하지 않기를 바랍니다. 그러나 그러한 도구를 사용하는 경우 다시 한 번 고치기가 어렵고 비즈니스 비용 및 / 또는 많은 비용 및 / 또는 시간이 들지 않습니다. 그러나 나쁜 영향을 미쳤다면 일부는 파일 이름에 대문자와 공백을 사용하는 것이 나쁜 습관이라고 과거에 말한 것을 기억할 것입니다.

그리고 마지막 한가지, 당신이 모든 문제를 방지하려면 , 어떤 특수 문자를 파일 이름에이 (경우에만 문자, 숫자, 밑줄 및 적자를 낮출 수 없음 [1]). 이 원치 않는 문자 목록에는 모든 비 ASCII 문자 (예, 프랑스어 및 영어가 아닌 다른 영어 사용자도 포함)가 포함됩니다. 나는 그 중 하나가 아닙니다 : à, â, ä, ç, é, ..., ö, æ, œ ...). 이것은 또한 login 및 password를 포함한 다른 많은 것들로 확장됩니다 . 확인 된 sysadmin이 작성하지 않은 bash 스크립트로 처리되는 로그인 또는 암호에 따옴표 또는 큰 따옴표 ( '또는 ") 를 넣을 때 어떤 일이 발생하는지 짐작할 수 있습니다 ....

[1] : 어쩌면 우리는에 있음을 확장 할 수있다 ~, @, #(... 그래 내가 이맥스 파일에 대해 알고) 및 일부 다른,하지만이 문제를 찾고 있습니다.