it-swarm-ru.tech

Соглашение об именовании файлов Unix

Мне было интересно, что такое соглашение об именах файлов в Unix? Я не уверен в этом, но я думаю, что существует универсальное соглашение об именах, которому нужно следовать?

Например, я хочу присвоить файлу имя: backup с part 2 и ​​random

Должен ли я сделать это так:

backup_part2_random

OR

backup-part2-random

OR

backup.part2.random

Я надеюсь, что вопрос ясен. По сути, я хочу выбрать формат, который соответствует философии Unix.

67
user4740

. используется для разделения расширения типа файла, например, foo.txt.

- или _ используется для разделения логических слов, например, my-big-file.txt или иногда my_big_file.txt. - лучше, потому что вам не нужно нажимать клавишу Shift (по крайней мере, на стандартной клавиатуре ПК на американском английском), другие предпочитают _ потому что это больше похоже на пространство.

Так что, если я понимаю ваш пример, backup-part2-random или backup_part2_random будет ближе всего к обычному соглашению Unix.


CamelCase обычно не используется в системах Linux/Unix. Посмотрите на имена файлов в /bin а также /usr/bin. CamelCase является скорее исключением, чем правилом в системах Unix и Linux.

(NetworkManager единственный пример, который я могу вспомнить, который использует CamelCase, и он был написан разработчиком Mac. Многие жаловались на такой выбор имени. В Ubuntu они фактически переименовали скрипт в 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
61
Mikel

Далеко более важно, что конкретное соглашение является последовательным. Выберите стиль и придерживайтесь его.

38
David Oneill

Мой взгляд на соглашения об именах файлов Unix/Linux:

  • Файловые системы Unix/Linux по своей природе не поддерживают понятие расширения. Концепция расширения файла полностью существует как нечто, поддерживаемое такими утилитами, как cp, ls или используемой оболочкой. Я верю, что это так и на NTFS, но я могу ошибаться.

  • Исполняемые файлы, включая сценарии оболочки, обычно никогда не имеют каких-либо расширений. Скрипты будут иметь строку хеш-бэнга (т. Е. #!/bin/bash) определяет, какая программа должна его интерпретировать.

  • Любой исполняемый файл длиной в две буквы очень важен. Поэтому не называйте свои исполняемые файлы двухбуквенными именами файлов. Любой файл в /etc, заканчивающийся на tab, также очень важен, например fstab, mtab, inittab.
  • Иногда .d добавляется к именам каталогов, особенно в /etc, но это не широко распространено (ОБНОВЛЕНИЕ: https://serverfault.com/questions/240181/what-does-the-suffix-d-mean-in-linux )
  • rc широко используется для конфигурационных сценариев или файлов, либо предваряющих (например, rc.local) или суффикс (.vimrc)
  • Сообщество Unix/Linux никогда не имело трехсимвольного ограничения на расширения и хмурится при сокращении хорошо известных расширений для соответствия. Например, не используйте .htm в конце HTML-файлов в Unix/Linux используйте .html.
  • В наборе файлов имя файла иногда пишется с большой буквы или заглавными буквами, поэтому оно появляется в начале списка каталогов. Классический пример - Makefile в исходных пакетах. Делайте это только для таких вещей, как README.
  • ~ используется для идентификации файла резервной копии или каталога, как в important_stuff~, или /etc~. Многие снаряды расширят одиночество ~ до $HOME.
  • Библиотечные файлы почти всегда начинаются с lib. Исключение составляет zlib и, возможно, несколько других.
  • Сценарии, вызываемые inetd, иногда помечаются лидирующим in., такие как in.tftpd.
  • Окончание z в vmlinuz означает zip, но я никогда не видел ни одного другого файла с таким именем.
19
LawrenceC

В Unix имя файла - это просто строка, в отличие от DOS, где имя файла составлено из имени и расширения. Таким образом, любое из заданных имен файлов полностью приемлемо.

Но многие программы по-прежнему используют файловые суффиксы, начинающиеся с точки, чтобы различать разные типы файлов, то есть веб-сервер Apache использует суффиксы для установки правильного типа MIME в заголовках ответов.

7
gelraen

Две мысли:

  1. В Naming Variables, Functions, and Files раздел Стандарты кодирования GN вы найдете:

    Пожалуйста, используйте подчеркивание для разделения слов в имени, чтобы команды Emacs Word могли быть полезны внутри них. Придерживаться нижнего регистра;

    В то время как ИМО говорит: "Вы должны использовать _ потому что emacs "кажется немного устаревшим, тем не менее, он есть в их документе о стандартах.

  2. Давайте на минутку предположим, что мы все согласны с тем, что ядро ​​linux является основным и все конечным * в проектах linux, и что используемые здесь соглашения можно считать "стандартным" соглашением.

    grep- ing источник для ядра linux вы найдете следующее:

    • 44,6% от времени, когда используется только тире
    • 54,1% только подчеркивание времени
    • 1,2% времени, когда файл использует оба.

Интересно, что источник для git весит при 85% для тире, 3,8% для подчеркивания и 11,1% для обоих.

Выбор ясен, дискуссия окончена. ;)

Личное мнение: Я использую тире по эстетическим и ключевым причинам. Если вы работаете в команде, проведите голосование. Но чтобы повторить сказанное, будьте последовательны.

* или "be_all and end_all", если хотите

6
Roy Truelove

Символы, которые вы не должны использовать в именах файлов:

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

Разделители символов, которые вы должны использовать, чтобы облегчить чтение имен:

_ -. :

(В некоторых случаях ":" имеет особое значение, хотя)

4
Istvan

Чтобы добавить к тому, что сказали другие, я бы просто сказал, что, хотя в именах файлов допустимы буквы с акцентом и многие специальные символы, они могут вызывать проблемы в любом из следующих сценариев:

  • Вы делите свою файловую систему с другими компьютерами, особенно с другими операционными системами;
  • Вы делитесь файлами с другими (и хотя электронная почта имеет тенденцию быть довольно хорошей с конверсиями, иногда она просто не работает);
  • Вы используете сценарии оболочки для автоматизации некоторых задач (пробелы особенно проблематичны, хотя есть много способов с ними справиться);
  • Вы используете общий файловый ресурс с другого компьютера.

...

4
asoundmove

Придерживайтесь буквенно-цифровых имен файлов. Избегайте пробелов или заменяйте пробелы подчеркиванием (_). Ограничьте знаки препинания в именах файлов точками (.), Символами подчеркивания (_) и дефисами (-). Обычно имена файлов строчные, но я использую CamelCase, когда в имени файла несколько слов.

Используйте расширения, которые указывают тип файла. Программы не нуждаются в расширениях, поскольку бит выполнения используется для обозначения программ, а оболочки знают, как запускать программы различных типов. Это (но не обязательно) для (.sh) для сценариев оболочки и (.pl) для сценариев Perl. Расширения исполняемых файлов Windows .bat, .com, .scr и .exe указывают исполняемые файлы Windows в Unix.

Выберите стандарт и придерживайтесь его. Но это не сломает вещи, если вы избежите этого.

Скрытые (или точечные) файлы имеют имена, начинающиеся с точки. Обычно они не отображаются в списках каталогов. Используйте 'ls -a', чтобы включить точечные файлы в список.

3
BillThor

использовать - или _ для именования файлов
_ для функций
. для расширений

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

Одним из соглашений является использование "_" для замены пробелов в качестве разделителей между словами. Другие символы могут быть использованы для замены пробелов, но есть более сильные обычные варианты использования "-" и "." в путевых именах, поэтому "_" обычно предпочтительнее.

Пробелы допустимы в путевых именах, но их обычно избегают, поскольку они требуют заключать в кавычки путь ("foo bar") или экранировать пробелы (foo\bar). Правильно написанный сценарий Shell будет заключать в кавычки переменные, которые могут включать пробелы, в частности, имена путей, но неисполнение этого является обычным упущением, и при вводе одноразовой команды, вводимой в командной строке, требуется много лишнего ввода.

Использование "-" для разделения кластеров чисел, таких как метки времени или серийные номера, является соглашением, обычно используемым вне контекста файловых систем. С помощью "." отделить "расширения файлов", которые указывают тип файла, очень распространено, и некоторые важные инструменты зависят от него. Например, система управления пакетами в Red Hat Enterprise Linux и ее производных RPM ожидает, что файлы пакетов будут заканчиваться на ".rpm". Традиционный tarball - это tar-файл (".tar"), который был распакован (".gz") и поэтому заканчивается на ".tar.gz".

Поэтому, собрав их вместе, вы часто получаете имена файлов, которые выглядят как "home_backup_2017-07-01.tar.gz"

2
bgvaughan

Я согласен с Дэвидом Онеилом, что тебе следует просто пойти с чем-то.

Но хорошо, если файлы сортируются в одном и том же каталоге, поэтому не номер 0 .. 10, а номер 00 .. 10.

При использовании дат в именах используйте стандартный формат даты, например ISO8601 .

И не бойтесь использовать несколько символов для разделения логических частей в имени. Если вы используете _ (это было 3 _), вы можете позже упростить регулярные выражения для имен файлов.

Таким образом, ваш пример может быть примерно таким:

backup_2011-06-19T114012___part002___random

Легко читается и легко разбирается со скриптами.

0
Johan

Слова в имени файла могут быть разделены с помощью _ или - в соответствии с конвенцией Unix.

Если вы используете -, легче набирать, избавляет вас от нажатия SHIFT. Но с тех пор - занимает так мало места, что трудно читать разделение Word по сравнению с _. С помощью _ разделение слов делает его намного чище, поскольку _ занимает больше места.

В сценариях Shell и другом компьютерном программировании _ используются для нескольких переменных Word, например MY_ENVIRONMENT_FILE. Заставить имена файлов использовать _ также сохраняет его согласованным: MY_ENVIRONMENT_FILE=~/my_environment_file.

В веб-разработке - предпочтительнее для именования файлов. Одна из причин, вероятно, заключается в том, что подчеркивание в веб-ссылках может скрыть подчеркивания и может затруднить ввод текста вручную.

В большинстве редакторов, а также на веб-страницах this_long_Word можно полностью выбрать двойным щелчком, но не this-long-Word.

0
GMaster