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

61

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

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

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

backup_part2_random

ИЛИ ЖЕ

backup-part2-random

ИЛИ ЖЕ

backup.part2.random

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

SLM
источник
4
В качестве общего комментария по поводу «условностей» ... Я только что прочитал все ответы до сих пор, и мне показалось странным, что существует почти одержимость использованием только одного случая в системе, где (я думаю) Одной из его сильных сторон является способность осмысленно использовать оба случая ... Был ли оригинальный дизайн (чувствителен к регистру) чрезмерным дизайном) ... просто размышления
Peter.O
Мое мнение: нет конвенции. Имена файлов - это просто строки. выбери свой любимый стиль.
Гленн Джекман
1
Это потому, что никто не хочет помнить заглавные буквы команд, поэтому они все используют одно и то же.
LtWorf

Ответы:

58

.используется для разделения расширения типа файла, например 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
Mikel
источник
Символ .также можно использовать для поворота вещей, а не только для указания расширения. Например my.log my.log.1 my.log.2.gz.
Депадо
Таким образом, дефис / минус / тире встречается чаще, чем подчеркивание.
Хьюго
@Хьюго Да. Выше показано минус (409) против подчеркивания (178).
Микель
Благодарю. У вас есть какие-либо ссылки на эти конвенции?
Пролетариат
3
+1 за ссылки. (@Proletariat, то lsвыводится /usr/bin это . Ссылка Это вопрос о конвенциях. )
Джокер
36

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

Дэвид Онеилл
источник
19

Мой взгляд на соглашения об именах файлов 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, но я никогда не видел ни одного другого файла с таким именем.
LawrenceC
источник
2
Я часто вижу сценарии оболочки с .sh«расширением» на них. Я лично нахожу это несколько раздражающим, но я должен признать, что я могу не знать о какой-то веской причине для использования .sh.
Дэн Молдинг
4
Напоминает, что полезно подчеркнуть тот факт, что это текстовый скрипт, а не двоичный.
LawrenceC
1
@DanMoulding, лично я использую .shсценарии, которые (1) не предназначены для интерактивного запуска, а только из других сценариев / программ, или (2) предназначены для поиска, а не выполнения. Для первых они должны быть исполняемыми; для последнего я оставляю исполняемый бит выключенным и использую строку shebang только для документации того, для какой оболочки написаны функции.
Wildcard
3
@Wildcard Я с тех пор (6 лет назад) вошел в эту же привычку. Расширение действительно имеет большой смысл для битов сценария поиска. Например, из исполняемого скрипта, написанного для zsh (то есть #!/bin/zshвверху), вы знаете, что можете безопасно получить другой файл с расширением .zsh и быть уверенным, что он содержит допустимый код zsh. Если ваш исполняемый скрипт строго совместим с Bourne Shell (т. #!/bin/shЕ. Вверху), то вы знаете, что поиск этого файла .zsh будет проблематичным.
Дэн Молдинг
4
Я считаю, что использование ".sh", ".py", ".pl" и т. Д. Удобно, и некоторые текстовые редакторы (например, Geany) используют их, чтобы сделать первое предположение о правильной схеме подсветки синтаксиса.
bgvaughan
7

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

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

gelraen
источник
5
Хотя gelraen верен на 100%: Unix / Linux как таковая не заботится о расширениях файлов, современные разновидности Linux заботятся о том, что некоторые расширения оболочки обеспечивают специальную идентификацию (цвета или иное) определенных типов файлов, а файловые менеджеры обеспечивают автоматические ассоциации с программами. Но так же важно, чтобы пользователь знал, какой файл какого типа. Для этого удобно придерживаться стандартной схемы не только для себя, но и для других. В этом отношении все не должно сильно отличаться от MS Windows (или MIME).
asoundmove
Тем не менее, иногда несколько разных стилей расширения могут соответствовать одной цели. Таким образом, .tar.gz эквивалентно .tgz, .tar.bz2 = .tbz, .ps.gz часто сокращается как .ps (смущает), и я уверен, что их гораздо больше.
asoundmove
@asoundmove .ps.gz означает, что это сжатый файл .ps. Также как .tar.gz означает сжатый файл .tar.
Jonescb
1
@jonescb, да, конечно. Моя точка зрения о том, что это сбивает с толку, заключается в том, что когда я вижу .ps, я ожидаю несжатый файл (который я должен уметь катать или меньше), но часто файлы .ps сжимаются и на самом деле должны быть .ps.gz для ясности ( поскольку они требуют zcat или zless для просмотра исходного кода). Некоторые люди решили просто добавить суффикс сжатых файлов PostScript к .ps, потому что некоторые распространенные программы просмотра ps на самом деле не обращают внимания на то, сжаты они или нет.
asoundmove
6

Две мысли:

  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", если хотите

Рой Truelove
источник
4

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

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

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

_ -. :

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

Иштван
источник
5
Конечно, вы даже не можете использовать «/» в именах файлов. Все остальное возможно. И если вы хотите затруднить доступ, даже полезно ;-)
Юрген А. Эрхард
Список на самом деле намного длиннее, включая управляющие и не-ASCII символы. Да, вы можете использовать backspace как часть имени файла * nix.
10
1
Более того, большинство систем * nix запрещают использовать только два конкретных символа в именах файлов: /разделитель пути и ограничитель строки \ 0 (ASCII ноль).
CVn
4

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

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

...

asoundmove
источник
3

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

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

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

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

BillThor
источник
5
CamelCase - это анти-паттерн в Unix. ФП спрашивал о конвенциях.
Микель
2
Это не «плохо» против «хорошо». Это «как обычно». Это соглашение, о котором просил ФП. Причина? Это может быть из-за того, что люди из Unix не любят нажимать Shift, или из-за того, что старые системы имеют только UPPERCASE, или по другой причине. Я не уверен.
Микель
@Mikel Я также программирую Java, где CamelCase является соглашением. Иногда шаблоны и соглашения противоречат друг другу.
BillThor
.scr также является исполняемым расширением Windows.
LawrenceC
1
@ultrasawblade Спасибо, показывает, как часто я пишу Windows. Я попытался пропустить более редкие исполняемые расширения, такие как cmd, pif, vb *, wsh и другие.
BillThor
2

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

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

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

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

bgvaughan
источник
2

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

cat << EOF > foo-bar.sh  
foo_bar() {  
echo baz  
}  
EOF  
Ахиль Дж
источник
0

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

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

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

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

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

backup_2011-06-19T114012___part002___random

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

Johan
источник
0

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

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

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

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

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

GMaster
источник
Хммм, почему вы читаете ваши имена файлов шрифтом переменной ширины? Откройте свой терминал и -и _взять только точно такое же пространство! :)
Wildcard
Хаха, ты прав. Я использую SourceCodePro + Powerline + Awesome Regular пропатченный шрифт. Даже с моноширинными шрифтами _выглядит чище, хотя и занимает столько же места, сколько и -. Я должен был использовать слово «по-видимому». Что касается _и -при использовании моноширинных шрифтов, разницу лучше всего объяснить с помощью этой аналогичной картины: evsc.net/v8/wp/wp-content/uploads/2010/09/…
GMaster,
-1

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

Билл Чатфилд
источник
-2

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

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

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

Ицхака
источник
5
-1. CamelCase НЕ используется в Linux.
Микель