перепишите_этот_заголовок_в_русском_порядке_именования_файлов_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 (по крайней мере, с обычной клавиатурой US English), некоторые предпочитают _, потому что это выглядит больше как пробел.

Таким образом, если я правильно понимаю ваш пример, 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 -l    # файлы, начинающиеся с заглавной буквы
6
$ ls -d *_* | wc -l       # файлы, содержащие подчеркивание
178
$ ls -d *-* | wc -l       # файлы, содержащие дефис
409

И даже тогда ни один из файлов, начинающихся с заглавной буквы, не использует CamelCase:

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

Гораздо важнее соблюдать определенную конвенцию и быть последовательным. Выберите стиль и придерживайтесь его.

Мои взгляды на конвенции имен файлов в Unix/Linux:

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

• Исполняемые файлы, включая shell-скрипты, обычно никогда не имеют никаких типов расширений. Скрипты будут иметь строку 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 означает сжатие, но я никогда не видел других файлов, названных таким образом.

Две мысли:

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

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

   Хотя на мой взгляд, утверждение “Вы должны использовать _, потому что emacs” кажется немного устаревшим, тем не менее оно содержится в их документе ‘стандартов’.

2. Допустим на минуту, что мы все согласны, что ядро Linux является единственным и окончательным* проектом Linux, и что конвенции, используемые там, можно считать ‘стандартными’.

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

   • 44.6% случаев используется только дефис
   • 54.1% случаев используется только подчеркивание
   • 1.2% случаев файл использует оба.

Интересно, что исходный код git имеет 85% для дефисов, 3.8% для подчеркиваний и 11.1% для обоих.

Выбор очевиден, дебаты завершены. 😉

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

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

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

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

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

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

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

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

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

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

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

_ – . :

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

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

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

…

• используйте - или _ для наименования файлов

• _ для функций

• . для расширений

пример:

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

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

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

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

Собирая все это вместе, вы часто сталкиваетесь с именами файлов, которые выглядят так: “home_backup_2017-07-01.tar.gz”

Я соглашаюсь с Дэвидом О’Нилом, что вам просто нужно выбрать что-то.

Но было бы приятно, если бы файлы сортировались в одном каталоге,
поэтому не нумеруйте от 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 Standards Base, который я сейчас не могу найти. Это также указано в документах GNU, которые говорят использовать подчеркивания для имен переменных и дефисы для имен файлов.

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

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

2. CamelCaps, похоже, проще использовать в скриптах, без вредных символов, о которых нужно беспокоиться.