Соглашение об именовании файлов Unix [закрыто]

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

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

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

backup_part2_random

ИЛИ ЖЕ

backup-part2-random

ИЛИ ЖЕ

backup.part2.random

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

.используется для разделения расширения типа файла, например 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

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

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

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

• Исполняемые файлы, включая сценарии оболочки, обычно никогда не имеют каких-либо расширений. Скрипты будут иметь строку hashbang (т. Е. #!/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, но я никогда не видел ни одного другого файла с таким именем.

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

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

Две мысли:

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

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

   В то время как IMO говорит «Вы должны использовать, _потому что emacs» кажется немного устаревшим, тем не менее, оно есть в их «стандарте».

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

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

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

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

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

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

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

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

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

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

_ -. :

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

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

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

...

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

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

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

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

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

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

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

Таким образом, объединяя их, вы часто получаете имена файлов, которые выглядят как «home_backup_2017-07-01.tar.gz»

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

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

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

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

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

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

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

backup_2011-06-19T114012___part002___random

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

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

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

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

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

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

Определенно есть стандарт для Linux. Если вы посмотрите на имена файлов в любой системе Linux, они будут в нижнем регистре с тире: / usr / bin / ssh-keygen. Это указано в одном из документов Стандартной базы Linux, который я не могу найти прямо сейчас. Он также указан GNU, который говорит использовать подчеркивания для имен переменных и тире для имен файлов.

Чтобы добавить к тому, что все остальные сказали:

1. Хотя Linux не заботится о расширениях, Windows заботится о них, поэтому убедитесь, что у любого файла, который вы когда-либо планируете предоставить кому-либо, есть соответствующее расширение.

Заголовки с 2 верблюдами, кажется, являются самыми простыми в использовании сценариями, без специальных символов, чтобы беспокоиться о escape-последовательностях.