유닉스 파일 명명 규칙 [닫힘]

유닉스에서 파일의 명명 규칙이 무엇인지 궁금합니다. 나는 이것에 대해 확실하지 않지만, 반드시 따라야 할 보편적 인 명명 규칙이 있다고 생각합니까?

예를 들어, 파일 이름을 다음 backup과 같이 지정 part 2하고 싶습니다.random

내가 이렇게해야합니까?

backup_part2_random

또는

backup-part2-random

또는

backup.part2.random

질문이 명확하기를 바랍니다. 기본적으로 유닉스 철학에 맞는 형식을 선택하고 싶습니다.

.파일 형식 확장자를 구분하는 데 사용됩니다 (예 :) foo.txt.

-또는 _논리적 단어를 분리하는 데 사용됩니다 (예 : my-big-file.txt또는 때때로) my_big_file.txt. -Shift 키 (적어도 표준 미국 영어 PC 키보드 사용)를 누를 필요가 없기 때문에 더 좋습니다. 다른 사람들은 _공간처럼 보이기 때문에 선호 합니다.

따라서 귀하의 예를 이해 backup-part2-random하거나 backup_part2_random일반적인 유닉스 관습에 가장 가까운 경우.

CamelCase는 일반적으로 Linux / Unix 시스템에서 사용되지 않습니다. /bin및의 파일 이름을 살펴보십시오 /usr/bin. CamelCase는 Unix 및 Linux 시스템의 규칙이 아니라 예외입니다.

( NetworkManager내가 생각할 수있는 유일한 예는 CamelCase를 사용하며 Mac 개발자가 작성한 것입니다. 많은 사람들 이이 이름 선택에 대해 불평했습니다. 우분투에서는 실제로 스크립트의 이름을로 변경했습니다 network-manager.)

예를 들어 /usr/bin내 시스템에서 :

$ ls -d [A-Z]* | wc -w    # files starting with a capital
6
$ ls -d *_* | wc -w       # files containing an underscore
178
$ ls -d *-* | wc -w       # files containing a minus/dash
409

그럼에도 자본으로 시작하는 파일은 CamelCase를 사용하지 않습니다.

$ ls -d [A-Z]*
GET  HEAD  POST  X11  Xvnc  Xvnc4

훨씬 더 중요한 특정 규칙은 일관되고 있음. 스타일을 고르십시오.

유닉스 / 리눅스 파일 이름 규약에 대한 나의 견해 :

• 유닉스 / 리눅스 파일 시스템은 기본적으로 확장 개념을 지원하지 않습니다. 뭔가 같은 유틸리티가 지원하는 파일 확장자의 개념은 완전히 존재 cp, ls또는 당신이 사용하는 쉘. NTFS 에서도이 방법이라고 생각하지만 잘못되었을 수 있습니다.

• 쉘 스크립트를 포함한 실행 파일은 일반적으로 어떤 유형의 확장명도 갖지 않습니다. 스크립트에는 #!/bin/bash해석해야 할 프로그램을 식별 하는 해시 뱅 라인 (예 :)이 있습니다 .

• 두 글자 길이의 실행 파일은 매우 중요합니다. 따라서 실행 파일 이름을 두 글자로 된 파일 이름으로 지정하지 마십시오. 에있는 모든 파일 /etc의 끝은 tab또한 다음과 같은, 매우 중요하다 fstab, mtab, inittab.
• 때때로 .d디렉토리 이름에 추가되는 경우 가 /etc있지만 특히 널리 퍼져 있지는 않습니다 (UPDATE : https://serverfault.com/questions/240181/what-does-the-suffix-d-mean-in-linux )
• rc접두사 (예 rc.local:) 또는 접미사 ( .vimrc) 와 같은 구성 스크립트 또는 파일에 널리 사용됩니다.
• 유닉스 / 리눅스 커뮤니티는 확장 기능에 대해 3 자로 제한하지 않았으며 잘 알려진 확장 기능을 줄이면 눈살을 찌푸립니다. 예를 들어, .htm유닉스 / 리눅스에서 HTML 파일의 끝에는 사용하지 마십시오 .html.
• 파일 세트에서 파일 이름은 대문자 또는 대문자로 표시되기 때문에 디렉토리 목록 헤드에 나타납니다. 고전적인 예는 Makefile소스 패키지에 있습니다. 같은 것들에 대해서만이 작업을 수행하십시오 README.
• ~같이 백업 파일이나 디렉토리를 식별하는 데 사용됩니다 important_stuff~, 또는 /etc~. 많은 껍질이 고독 ~으로 확장 됩니다 $HOME.
• 라이브러리 파일은 거의 항상로 시작합니다 lib. 예외는 zlib아마도 몇 가지 일 것입니다.
• inetd에 의해 호출 된 스크립트는 때때로과 같이 선행으로 태그가 지정 in.됩니다 in.tftpd.
• 끝나는 z vmlinuz는 압축 을 의미하지만 이런 식으로 명명 된 다른 파일은 본 적이 없습니다.

유닉스에서 파일 이름은 DOS와 달리 문자열이며 파일 이름은 이름과 확장명으로 구성됩니다. 따라서 주어진 파일 이름 중 어느 것이 든 허용됩니다.

그러나 많은 프로그램은 여전히 ​​점으로 시작하는 파일 접미사를 사용하여 다른 파일 형식을 구별합니다. 즉, Apache Web Server는 접미사를 사용하여 응답 헤더에 올바른 MIME 유형을 설정합니다.

두 가지 생각 :

1. 에서 Naming Variables, Functions, and Files의 섹션 GNU 코딩 표준 이 찾을 수 있습니다 :

   밑줄을 사용하여 이름에서 단어를 분리하면 Emacs 단어 명령이 그 안에 유용 할 수 있습니다. 소문자를 고수하십시오;

   IMO가 " _emacs 때문에 사용해야한다"고 말하는 것은 다소 오래된 것으로 보이지만 그럼에도 불구하고 '표준'문서에 있습니다.

2. 우리가 모두 리눅스 커널이 리눅스 프로젝트의 가장 중요한 *이고, 사용 된 규약이 '표준'규약으로 간주 될 수 있다는 것에 우리 모두가 동의한다고 가정하자.

   grep-ing 리눅스 커널의 소스를 다음을 찾을 수 있습니다 :

   • 대시 만 사용 된 시간의 44.6 %
   • 시간의 54.1 % 가 밑줄 만
   • 파일이 둘 다 사용하는 시간의 1.2 %

흥미롭게도, 자식에 대한 소스 의 무게 는 85 % 대시를 들어, 3.8 %, 밑줄, 및 11.1 % 모두.

선택은 분명하고 논쟁입니다. ;)

개인적 견해 : 나는 미적 요소와 변화의 주요 이유 때문에 대시를 사용합니다. 팀에서 일하고 있다면 투표하십시오. 그러나 말한 내용을 되풀이하려면 일관성을 유지하십시오 .

* 또는 원하는 경우 "be_all and end_all"

파일 이름에 사용해서는 안되는 문자 :

| ; ,! @ # $ () <> / \ " '`~ {} [] = + & ^

이름을보다 쉽게 ​​읽을 수 있도록하는 문자 분리 문자 :

_-. :

(어떤 경우에는 ":"에 특별한 의미가 있습니다)

다른 사람들의 말을 더하기 위해, 악센트 부호 문자와 많은 특수 문자가 파일 이름에 합법적이지만 다음 시나리오 중 하나에서 문제를 일으킬 수 있다고 말하고 싶습니다.

• 파일 시스템을 다른 컴퓨터, 특히 다른 운영 체제와 공유합니다.
• 다른 사용자와 파일을 공유합니다 (이메일은 변환에 상당히 도움이 되더라도 작동하지 않는 경우가 있습니다).
• 쉘 스크립트를 사용하여 일부 작업을 자동화합니다 (공백은 처리 방법이 많지만 공간이 특히 문제가됩니다).
• 다른 컴퓨터에서 파일 공유를 사용합니다.

...

영숫자 파일 이름을 고수하십시오. 공백을 피하거나 공백을 밑줄 (_)로 바꾸십시오. 파일 이름의 구두점을 마침표 (.), 밑줄 (_) 및 하이픈 (-)으로 제한하십시오. 일반적으로 파일 이름은 소문자이지만 파일 이름에 여러 단어가 있으면 CamelCase를 사용합니다.

파일 형식을 나타내는 확장명을 사용하십시오. 실행 비트는 프로그램을 나타내는 데 사용되므로 프로그램은 확장이 필요하지 않으며 쉘은 다양한 유형의 프로그램을 실행하는 방법을 알고 있습니다. 쉘 스크립트의 경우 (.sh) 및 펄 스크립트의 경우 (.pl)이 일반적이지만 필수는 아닙니다. Windows 실행 파일 확장명 .bat, .com, .scr 및 .exe는 Unix의 Windows 실행 파일을 나타냅니다.

표준을 선택하고 준수하십시오. 그러나 피하지 않아도 문제가 발생하지 않습니다.

숨겨진 파일 (또는 점)은 마침표로 시작하는 이름을 갖습니다. 이들은 일반적으로 디렉토리 목록에 표시되지 않습니다. 점에 파일을 포함 시키려면 'ls -a'를 사용하십시오.

한 규칙은 "_"를 사용하여 단어 사이의 공백을 공백으로 대체하는 것입니다. 다른 문자는 공백을 대체하는 데 사용될 수 있지만 "-"및 "."에 대한 일반적인 용도는 약간 더 강력합니다. 경로 이름에서 "_"가 선호됩니다.

공백은 경로 이름에서 유효하지만 경로 이름을 인용 ( "foo bar")하거나 공백을 제거 (foo \ bar)해야하므로 일반적으로 사용하지 않습니다. 적절하게 작성된 쉘 스크립트는 공백, 특히 경로 이름을 포함 할 수있는 변수를 인용하지만, 그렇게하지 않는 것은 일반적인 감독이며, 명령 행에 입력 된 일회성 명령을 수행 할 때 많은 추가 입력이 있습니다.

타임 스탬프 또는 일련 번호와 같이 "-"를 사용하여 숫자 군집을 분리하는 것은 파일 시스템 컨텍스트 외부에서 일반적으로 사용되는 규칙입니다. "."사용 파일 형식을 나타내는 "파일 확장자"를 분리하는 것은 매우 일반적이며 일부 중요한 도구는 파일에 의존합니다. 예를 들어, Red Hat Enterprise Linux와 그 파생물 인 RPM의 패키지 관리 시스템은 패키지 파일이 ".rpm"으로 끝나기를 기대합니다. 기존의 타르볼은 압축 된 tar 파일 ( ".tar") ( ". gz")이므로 ".tar.gz"로 끝납니다.

따라서 이들을 합치면 종종 "home_backup_2017-07-01.tar.gz"와 같은 파일 이름으로 끝납니다.

확장 기능의 파일 이름 지정 -또는 사용_
_
.

cat << EOF > foo-bar.sh  
foo_bar() {  
echo baz  
}  
EOF  

나는 당신이 무언가로 가야한다는 David Oneill에 동의합니다.

그러나 파일이 동일한 디렉토리에 정렬 가능하면 좋을 것이므로 0 ..10은 아니지만 00 ..10 은 사용하지 마십시오.

이름에 날짜를 사용할 때는 ISO8601 과 같은 표준 날짜 형식을 사용하십시오 .

그리고 여러 문자를 사용하여 이름의 논리 부분을 분리하는 것을 두려워하지 마십시오. 당신이 사용하는 경우 _ 당신은 나중에 파일 이름에 regexps '에를 단순화 할 수 있습니다 (즉 _ 3이었다).

따라서 귀하의 예는 다음과 같습니다.

backup_2011-06-19T114012___part002___random

스크립트로 쉽게 읽고 구문 분석 할 수 있습니다.

파일 이름의 단어는 유닉스 규칙에 따라 _또는 -유닉스 규칙에 따라 분리 할 수 ​​있습니다 .

을 사용 -하면 입력하기가 쉬워 SHIFT를 누를 필요가 없습니다. 그러나 -공간이 거의 없기 때문에에 비해 단어 구분을 읽는 것이 약간 어렵습니다 _. 더 많은 공간을 차지 _하므로 단어를 구분하는 데 사용하면 훨씬 깔끔해 보입니다 _.

쉘 스크립팅 및 기타 컴퓨터 프로그래밍 _에서와 같이 여러 단어 변수에 사용됩니다 MY_ENVIRONMENT_FILE. 파일 이름을 그대로 사용하면 파일 이름 _이 일관되게 유지됩니다 MY_ENVIRONMENT_FILE=~/my_environment_file.

웹 개발에서는 -파일 이름 지정이 선호됩니다. 한 가지 이유는 웹 링크의 밑줄이 밑줄을 숨길 수 있고 웹 링크를 직접 입력하는 경우 어려울 수 있기 때문일 수 있습니다.

웹 페이지뿐만 아니라 대부분의 편집자에서는 this_long_word더블 클릭으로 완전히 선택할 수 있지만을 클릭 할 수는 없습니다 this-long-word.

리눅스에는 분명히 표준이 있습니다. Linux 시스템에서 파일 이름을 보면 / usr / bin / ssh-keygen과 같이 소문자로 표시됩니다. 이것은 현재 찾을 수없는 Linux Standards Base 문서 중 하나에 지정되어 있습니다. 또한 변수 이름에 밑줄을 사용하고 파일 이름에 대시를 사용하도록 GNU에서 지정합니다.

다른 사람들이 말한 것에 덧붙이려면 :

1- 비록 Linux는 확장에 관심이 없지만 Windows는 확장을 중요하게 생각하므로 다른 사람에게 제공하려는 모든 파일에 적절한 확장명이 있는지 확인하십시오.

2-Camel 캡은 이스케이프 시퀀스에 대해 걱정할 특수 문자가없는 스크립트를 사용하는 것이 가장 쉬운 것 같습니다.