Quy ước đặt tên tệp Unix [đã đóng]


61

Tôi đã tự hỏi quy ước đặt tên cho các tệp trong Unix là gì? Tôi không chắc chắn về điều này, nhưng tôi nghĩ có lẽ có một quy ước đặt tên phổ quát mà người ta nên tuân theo?

Ví dụ, tôi muốn đặt tên cho một tệp nói: backupvới part 2random

Tôi có nên làm như thế này không:

backup_part2_random

HOẶC LÀ

backup-part2-random

HOẶC LÀ

backup.part2.random

Tôi hy vọng câu hỏi là rõ ràng. Về cơ bản, tôi muốn chọn một định dạng phù hợp với triết lý Unix.


4
Như một nhận xét chung là "quy ước" ... Tôi mới đọc tất cả các câu trả lời, và điều đó làm tôi thấy kỳ lạ là gần như có một sự ám ảnh khi chỉ sử dụng một trường hợp trong một hệ thống trong đó (tôi nghĩ) một trong những thế mạnh của nó là khả năng sử dụng một cách có ý nghĩa cả hai trường hợp ... Là thiết kế ban đầu (phân biệt chữ hoa chữ thường) là một thiết kế vượt trội) ... chỉ là suy ngẫm
Peter.O

ý kiến ​​của tôi: không có quy ước. tên tệp chỉ là chuỗi. chọn phong cách yêu thích của bạn.
glenn jackman

1
Đó là bởi vì không ai muốn nhớ cách viết hoa của các lệnh, vì vậy tất cả chúng đều sử dụng như nhau.
LtWorf

Câu trả lời:


57

.được sử dụng để phân tách một phần mở rộng filetype, ví dụ foo.txt.

-hoặc _được sử dụng để phân tách các từ logic, ví dụ my-big-file.txthoặc đôi khi my_big_file.txt. -sẽ tốt hơn vì bạn không phải nhấn phím Shift (ít nhất là với bàn phím PC tiếng Anh tiêu chuẩn của Hoa Kỳ), những người khác thích _vì nó trông giống một khoảng trống hơn.

Vì vậy, nếu tôi hiểu ví dụ của bạn, backup-part2-randomhoặc backup_part2_randomsẽ gần nhất với quy ước Unix thông thường.


CamelCase thường không được sử dụng trên các hệ thống Linux / Unix. Có một cái nhìn vào tên tập tin trong /bin/usr/bin. CamelCase là ngoại lệ thay vì quy tắc trên các hệ thống Unix và Linux.

( NetworkManagerlà ví dụ duy nhất tôi có thể nghĩ về việc sử dụng CamelCase và nó được viết bởi một nhà phát triển Mac. Nhiều người đã phàn nàn về lựa chọn tên này. Trên Ubuntu, họ thực sự đã đổi tên tập lệnh thành network-manager.)

Ví dụ: /usr/bintrên hệ thống của tôi:

$ 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

và thậm chí sau đó, không có tệp nào bắt đầu bằng vốn sử dụng CamelCase:

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

Các .char cũng có thể được sử dụng để xoay mọi thứ, không chỉ để xác định một phần mở rộng. Ví dụ my.log my.log.1 my.log.2.gz.
Depado

Vì vậy, dấu gạch nối / dấu trừ / dấu gạch ngang phổ biến hơn là dấu gạch dưới.
Hugo

@Hugo Vâng. Trên đây cho thấy trừ (409) so với gạch dưới (178).
Mikel

Cảm ơn. Bạn có bất kỳ tài liệu tham khảo cho các công ước này?
Vô sản

3
+1 cho các tài liệu tham khảo. (@Proletariat, lsđầu ra từ /usr/bin một tài liệu tham khảo. Đây là câu hỏi về các quy ước. )
Wildcard

35

Viễn quan trọng hơn là một quy ước cụ thể được sự kiên định. Chọn một phong cách, và gắn bó với nó.


19

Tôi chấp nhận các quy ước tên tệp Unix / Linux:

  • Các hệ thống tập tin Unix / Linux vốn không hỗ trợ khái niệm về một phần mở rộng. Khái niệm về một phần mở rộng tập tin hoàn toàn tồn tại như một cái gì đó được hỗ trợ bởi các tiện ích như cp, lshoặc vỏ bạn đang sử dụng. Tôi tin rằng nó cũng theo cách này trên NTFS, nhưng tôi có thể sai.

  • Các tệp thực thi, bao gồm các tập lệnh shell, thường không bao giờ có bất kỳ loại tiện ích mở rộng nào. Các tập lệnh sẽ có một dòng hashbang (tức là #!/bin/bash) xác định chương trình nào sẽ diễn giải nó.

  • Bất kỳ thực thi nào dài hai chữ cái là siêu quan trọng. Vì vậy, đừng đặt tên tập tin thực thi hai chữ cái của bạn. Bất kỳ tập tin trong /etctận cùng bằng tabcũng là siêu quan trọng, chẳng hạn như fstab, mtab, inittab.
  • Đôi khi .dđược thêm vào tên thư mục, đặc biệt là trong /etc, nhưng điều này không phổ biến (CẬP NHẬT: https://serverfault.com/questions/240181/what-does-the-suffix-d-mean-in-linux )
  • rcđược sử dụng rộng rãi cho các tập lệnh hoặc tập tin cấu hình, hoặc là chuẩn bị trước (ví dụ rc.local:) hoặc hậu tố ( .vimrc)
  • Cộng đồng Unix / Linux chưa bao giờ có giới hạn ba ký tự đối với các tiện ích mở rộng và cau mày khi rút ngắn các tiện ích mở rộng cũng phải phù hợp. Ví dụ: không sử dụng .htmở cuối tệp HTML trên Unix / Linux, sử dụng .html.
  • Trong một tập hợp các tệp, một tên tệp đôi khi được viết hoa hoặc trong tất cả các chữ hoa, vì vậy nó xuất hiện ở đầu danh sách thư mục. Ví dụ cổ điển là Makefiletrong các gói nguồn. Chỉ làm điều này cho những thứ như README.
  • ~được sử dụng để xác định một tập tin sao lưu hoặc một thư mục, như trong important_stuff~, hoặc /etc~. Nhiều vỏ sẽ mở rộng một ~mình $HOME.
  • Các tập tin thư viện hầu như luôn luôn bắt đầu với lib. Ngoại lệ là zlibvà có lẽ một vài người khác.
  • Các tập lệnh được gọi bởi inetd đôi khi được gắn thẻ hàng đầu in., chẳng hạn như in.tftpd.
  • Chữ z kết thúc vmlinuzcó nghĩa là được nén, nhưng tôi chưa bao giờ thấy bất kỳ tệp nào khác có tên theo cách này.

2
Tôi thường thấy các kịch bản shell có .sh"phần mở rộng" trên chúng. Cá nhân tôi thấy nó hơi khó chịu, nhưng tôi phải thừa nhận rằng tôi có thể không biết gì về lý do chính đáng để sử dụng .sh.
Dan Mould

4
Một điều lưu ý rằng thật hữu ích khi nhấn mạnh thực tế rằng đó là một kịch bản dựa trên văn bản chứ không phải là một tệp nhị phân.
LawrenceC

1
@DanMoulding, cá nhân, tôi sử dụng .shtrên các tập lệnh (1) không có ý định chạy tương tác, mà chỉ từ các tập lệnh / chương trình khác, hoặc (2) được thiết kế để tìm nguồn cung ứng thay vì thực thi. Đối với trước đây họ phải được thực thi; để sau này tôi bỏ bit thực thi và chỉ sử dụng dòng shebang cho tài liệu về các hàm được viết cho shell.
tự đại diện

3
@Wildcard Tôi có từ (6 năm trước) có thói quen tương tự. Phần mở rộng thực sự có ý nghĩa rất lớn đối với việc tìm nguồn bit bit. Chẳng hạn, từ một tập lệnh thực thi được viết cho zsh (tức là #!/bin/zshở trên cùng), bạn biết rằng bạn có thể lấy nguồn khác một cách an toàn với phần mở rộng .zsh và chắc chắn rằng nó chứa mã zsh hợp pháp. Nếu tập lệnh thực thi của bạn hoàn toàn tuân thủ Bourne Shell (tức là #!/bin/shở trên cùng), thì bạn sẽ biết rằng việc tìm nguồn cung cấp tệp .zsh đó sẽ gặp vấn đề.
Dan Mould

4
Tôi thấy việc sử dụng ".sh", ".py", ".pl", v.v.
bgvaughan

7

Trong tên tệp unix chỉ là một chuỗi, không giống như DOS, nơi tên tệp được tạo từ tên và phần mở rộng. Vì vậy, bất kỳ tên tập tin đã cho là hoàn toàn chấp nhận được.

Nhưng nhiều chương trình vẫn sử dụng hậu tố tệp bắt đầu bằng dấu chấm để phân biệt các loại tệp khác nhau, tức là Máy chủ Web Apache sử dụng hậu tố để đặt loại MIME chính xác trong tiêu đề câu trả lời.


5
Mặc dù gelraen đúng 100%: Unix / Linux không quan tâm đến các phần mở rộng tệp, nhưng các hương vị hiện đại của Linux vẫn quan tâm đến mức một số phần mở rộng vỏ cung cấp nhận dạng đặc biệt (màu sắc hoặc cách khác) của một số loại tệp và trình quản lý tệp cung cấp liên kết tự động với các chương trình. Nhưng điều quan trọng là người dùng phải biết tập tin nào là loại nào. Cuối cùng, thật thuận tiện khi tuân theo một kế hoạch tiêu chuẩn không chỉ phù hợp với bản thân mà còn với những người khác. Về mặt này, mọi thứ không nên quá khác biệt so với MS Windows (hoặc MIME).
asoundmove

Điều đó nói rằng đôi khi một số kiểu mở rộng khác nhau có thể phù hợp với cùng một mục đích. Do đó .tar.gz tương đương với .tgz, .tar.bz2 = .tbz ,.
asoundmove

@asoundmove .ps.gz có nghĩa là tệp .ps được nén. Giống như .tar.gz có nghĩa là tệp .tar được nén.
jonescb

1
@jonescb, vâng tất nhiên rồi. Quan điểm của tôi về vấn đề khó hiểu là khi tôi nhìn thấy .ps tôi mong đợi một tệp không được nén (mà tôi có thể tạo ra hoặc ít hơn), nhưng thường thì các tệp .ps được nén và trên thực tế phải là .ps.gz cho rõ ràng ( vì họ yêu cầu zcat hoặc zless để xem mã nguồn). Một số người quyết định chỉ thêm hậu tố nén các tệp PostScript bằng .ps vì một số người xem ps thông thường thực sự không quan tâm liệu chúng có được nén hay không.
asoundmove

6

Hai suy nghĩ:

  1. Trong Naming Variables, Functions, and Filesphần Tiêu chuẩn mã hóa GNU bạn sẽ tìm thấy:

    Vui lòng sử dụng dấu gạch dưới để phân tách các từ trong một tên, để các lệnh từ Emacs có thể hữu ích trong chúng. Dính vào chữ thường;

    Mặc dù IMO nói rằng "Bạn nên sử dụng _vì emacs" có vẻ hơi lạc hậu, tuy nhiên nó vẫn nằm trong tài liệu 'tiêu chuẩn' của họ.

  2. Chúng ta hãy giả sử rằng tất cả chúng ta đều đồng ý rằng hạt nhân linux là tất cả và cuối cùng * của các dự án linux và các quy ước được sử dụng có những quy ước có thể được coi là 'tiêu chuẩn'.

    grep-ing nguồn cho kernel linux bạn sẽ tìm thấy như sau:

    • 44,6% thời gian chỉ sử dụng dấu gạch ngang
    • 54,1% thời gian chỉ gạch dưới
    • 1,2% thời gian một tập tin sử dụng cả hai.

Điều thú vị là, nguồn cho git nặng tới 85% cho dấu gạch ngang, 3,8% cho dấu gạch dưới và 11,1% cho cả hai.

Sự lựa chọn là rõ ràng, tranh luận về. ;)

Ý kiến ​​cá nhân: Tôi sử dụng dấu gạch ngang vì lý do thẩm mỹ và thay đổi. Nếu bạn đang làm việc trong một nhóm, hãy bỏ phiếu. Nhưng để nhắc lại những gì đã nói, hãy kiên định .

* hoặc "be_all và end_all" nếu bạn thích


4

Các ký tự bạn không nên sử dụng trong tên tệp:

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

Các ký tự phân cách bạn nên sử dụng để làm cho tên dễ đọc hơn:

_ -. :

(Trong một số trường hợp ":" có ý nghĩa đặc biệt)


5
Tất nhiên, bạn thậm chí không thể sử dụng "/" trong tên tệp. Mọi thứ khác đều có thể. Và nếu bạn muốn làm cho nó khó truy cập, thậm chí hữu ích ;-)
Jürgen A. Erhard

Danh sách này thực sự dài hơn rất nhiều, bao gồm các ký tự điều khiển và không phải ASCII. Có, bạn có thể có một backspace như là một phần của tên tệp * nix.
l0b0

1
Hơn nữa, hầu hết các hệ thống * nix chỉ không cho phép hai ký tự cụ thể trong tên tệp: /dấu phân cách đường dẫn và bộ kết thúc chuỗi \ 0 (ASCII zero).
một CVn

4

Để thêm vào những gì người khác đã nói, tôi chỉ nói rằng trong khi các chữ cái có dấu và nhiều ký tự đặc biệt là hợp pháp trong tên tệp, chúng có thể gây ra sự cố trong bất kỳ tình huống nào sau đây:

  • Bạn chia sẻ hệ thống tập tin của mình với các máy tính khác, đặc biệt là với các hệ điều hành khác nhau;
  • Bạn chia sẻ tệp với người khác (và mặc dù email có xu hướng khá tốt với chuyển đổi, đôi khi nó không hoạt động);
  • Bạn sử dụng các kịch bản shell để tự động hóa một số tác vụ (không gian đặc biệt có vấn đề, mặc dù có nhiều cách để xử lý chúng);
  • Bạn sử dụng một chia sẻ tập tin từ một máy tính khác.

...


3

Dán tên tệp chữ và số. Tránh không gian hoặc thay thế không gian bằng dấu gạch dưới (_). Giới hạn dấu câu trong tên tệp thành dấu chấm (.), Dấu gạch dưới (_) và dấu gạch nối (-). Nói chung tên tệp là chữ thường, nhưng tôi sử dụng CamelCase khi tôi có nhiều từ trong tên tệp.

Sử dụng các phần mở rộng chỉ ra loại tệp. Các chương trình không cần phần mở rộng vì bit thực thi được sử dụng để chỉ ra các chương trình và các shell biết cách chạy các chương trình thuộc nhiều loại khác nhau. Nó là phổ biến nhưng không bắt buộc (.sh) cho các tập lệnh shell và (.pl) cho các tập lệnh perl. Các phần mở rộng thực thi của Windows .bat, .com, .scr và .exe cho biết các tệp thực thi của Windows trên Unix.

Chọn một tiêu chuẩn và dính vào nó. Nhưng nó sẽ không phá vỡ mọi thứ nếu bạn tránh nó.

Các tệp ẩn (hoặc dấu chấm) có tên bắt đầu bằng dấu chấm. Chúng thường không hiển thị trong danh sách thư mục. Sử dụng 'ls -a' để đưa các tệp chấm vào danh sách.


5
CamelCase là một mô hình chống trên Unix. OP đã hỏi về các quy ước.
Mikel

2
Nó không "xấu" so với "tốt". Đó là "đây là cách nó thường được thực hiện". Đó là một quy ước mà OP đã yêu cầu. Nguyên nhân? Có thể là do người Unix không thích nhấn Shift, có thể là do các hệ thống cũ chỉ có UPPERCASE hoặc vì một lý do khác. Tôi không chắc.
Mikel

@Mikel Tôi cũng lập trình Java trong đó CamelCase là một quy ước. Đôi khi mô hình và quy ước xung đột.
BillThor

.scr cũng là một phần mở rộng thực thi của Windows.
LawrenceC

1
@ultrasawblade Cảm ơn, cho thấy tần suất tôi viết kịch bản Windows. Tôi đã cố gắng bỏ qua các phần mở rộng thực thi hiếm hơn như cmd, pif, vb *, wsh và phần còn lại của chúng.
BillThor

2

Một quy ước là sử dụng "_" để thay thế khoảng trắng làm dấu phân cách giữa các từ. Các ký tự khác có thể được sử dụng để thay thế khoảng trắng, nhưng có những cách sử dụng thông thường mạnh hơn một chút cho "-" và "." trong tên đường dẫn, vì vậy "_" thường được ưu tiên.

Dấu cách là hợp pháp trong tên đường dẫn, nhưng thường được tránh, vì chúng yêu cầu trích dẫn tên đường dẫn ("thanh foo") hoặc thoát khỏi khoảng trắng (foo \ bar). Một tập lệnh shell được viết đúng sẽ trích dẫn các biến có thể bao gồm khoảng trắng, đặc biệt là tên đường dẫn, nhưng không làm như vậy là một sự giám sát phổ biến và sẽ có rất nhiều thao tác gõ khi thực hiện lệnh một lần được nhập vào dòng lệnh.

Sử dụng "-" để phân tách các cụm số, như trong dấu thời gian hoặc số sê-ri, là một quy ước thường được sử dụng bên ngoài ngữ cảnh của các hệ thống tệp. Sử dụng "." để phân tách "phần mở rộng tệp" cho biết loại tệp rất phổ biến và một số công cụ quan trọng phụ thuộc vào nó. Chẳng hạn, hệ thống quản lý gói trên Red Hat Enterprise Linux và các dẫn xuất của nó, RPM, hy vọng các tệp gói sẽ kết thúc bằng ".rpm". Tarball truyền thống là một tệp tar (".tar") đã được nén (".gz"), và do đó kết thúc bằng ".tar.gz".

Vì vậy, đặt những thứ này lại với nhau, bạn thường kết thúc với tên tệp trông giống như, "home_backup_2017-07-01.tar.gz"


2

sử dụng -hoặc _để đặt tên tệp
_cho các chức năng
.cho tiện ích mở rộng

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

0

Tôi đồng ý với David Oneill rằng bạn chỉ nên đi với một cái gì đó.

Nhưng thật tuyệt nếu các tệp có thể sắp xếp trong cùng một thư mục, vì vậy đừng đánh số 0 ..10 mà là số 00 ..10.

Khi sử dụng ngày trong tên, hãy đi với định dạng ngày chuẩn như ISO8601 .

Và đừng ngại sử dụng nhiều ký tự để phân tách các phần logic trong tên. Nếu bạn sử dụng _ (đó là 3 _), thì bạn có thể đơn giản hóa các biểu thức chính trên tên tệp sau này.

Vì vậy, ví dụ của bạn có thể là một cái gì đó như thế này:

backup_2011-06-19T114012___part002___random

Dễ đọc và dễ phân tích cú pháp.


0

Các từ trong tên tệp có thể được phân tách bằng _hoặc -theo quy ước Unix.

Nếu bạn sử dụng -, việc nhập sẽ dễ dàng hơn, giúp bạn tiết kiệm khi nhấn SHIFT. Nhưng vì -chiếm quá ít không gian, nên hơi khó đọc các từ tách biệt so với _. Sử dụng _để tách các từ làm cho nó trông gọn gàng hơn vì _chiếm nhiều không gian hơn.

Trong kịch bản shell và lập trình máy tính khác, _được sử dụng cho các biến nhiều từ, như MY_ENVIRONMENT_FILE. Làm cho tên tệp sử dụng _cũng giữ cho nó nhất quán : MY_ENVIRONMENT_FILE=~/my_environment_file.

Trong phát triển web, -được ưa thích để đặt tên tập tin. Một lý do có lẽ là vì phần gạch chân trong các liên kết web có thể ẩn dấu gạch dưới và có thể gây khó khăn nếu bạn gõ liên kết web bằng tay.

Trong hầu hết các biên tập viên cũng như các trang web, this_long_wordcó thể được chọn hoàn toàn bằng một cú nhấp chuột nhưng không this-long-word.


Hmmm, tại sao bạn đọc tên tệp của bạn trong một phông chữ có chiều rộng thay đổi? Mở thiết bị đầu cuối của bạn -_chiếm chính xác cùng một không gian! :)
tự đại diện

Haha, bạn nói đúng Tôi sử dụng SourceCodePro + Powerline + Phông chữ vá thường xuyên tuyệt vời. Ngay cả với phông chữ đơn cách, _trông vẫn sạch hơn mặc dù nó có cùng không gian như -. Tôi nên sử dụng từ "rõ ràng". Về _-khi sử dụng phông chữ đơn cách, sự khác biệt có thể được giải thích rõ nhất với hình ảnh tương tự này: evsc.net/v8/wp/wp-content/uploads/2010/09/ Kẻ
GMaster

-1

Chắc chắn có một tiêu chuẩn cho Linux. Nếu bạn nhìn vào tên tệp trong bất kỳ hệ thống Linux nào thì chúng là chữ thường với dấu gạch ngang: / usr / bin / ssh-keygen. Điều này được chỉ định trong một trong các tài liệu Cơ sở Tiêu chuẩn Linux mà tôi không thể tìm thấy ngay bây giờ. Nó cũng được GNU chỉ định sử dụng dấu gạch dưới cho tên biến và dấu gạch ngang cho tên tệp.


-2

Để thêm vào những gì mọi người khác đã nói:

1-Mặc dù Linux không quan tâm nhiều đến các tiện ích mở rộng, Windows cũng vậy, vì vậy hãy đảm bảo mọi tệp bạn từng dự định cung cấp cho bất kỳ ai đều có tiện ích mở rộng phù hợp.

2-Mũ lạc đà dường như là tập lệnh dễ sử dụng nhất, không có ký tự đặc biệt nào phải lo lắng về các chuỗi thoát.


5
-1. CamelCase KHÔNG được sử dụng trên Linux.
Mikel
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.