Мне было интересно, что такое соглашение об именах файлов в 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
в моей системе:и даже тогда, ни один из файлов, начинающихся с заглавной буквы, не использует CamelCase:
источник
.
также можно использовать для поворота вещей, а не только для указания расширения. Напримерmy.log my.log.1 my.log.2.gz
.ls
выводится/usr/bin
это . Ссылка Это вопрос о конвенциях. )Гораздо важнее, что конкретное соглашение является последовательным. Выберите стиль и придерживайтесь его.
источник
Мой взгляд на соглашения об именах файлов 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
).htm
в конце HTML-файлы в Unix / Linux, используйте.html
.Makefile
в пакетах с исходным кодом. Делайте это только для таких вещей, какREADME
.~
используется для идентификации файла резервной копии или каталога, напримерimportant_stuff~
, или/etc~
. Многие снаряды расширятся одинокими~
в$HOME
.lib
. Исключением являютсяzlib
и, вероятно, некоторые другие.in.
, такими какin.tftpd
.vmlinuz
означает zip, но я никогда не видел ни одного другого файла с таким именем.источник
.sh
«расширением» на них. Я лично нахожу это несколько раздражающим, но я должен признать, что я могу не знать о какой-то веской причине для использования.sh
..sh
сценарии, которые (1) не предназначены для интерактивного запуска, а только из других сценариев / программ, или (2) предназначены для поиска, а не выполнения. Для первых они должны быть исполняемыми; для последнего я оставляю исполняемый бит выключенным и использую строку shebang только для документации того, для какой оболочки написаны функции.#!/bin/zsh
вверху), вы знаете, что можете безопасно получить другой файл с расширением .zsh и быть уверенным, что он содержит допустимый код zsh. Если ваш исполняемый скрипт строго совместим с Bourne Shell (т.#!/bin/sh
Е. Вверху), то вы знаете, что поиск этого файла .zsh будет проблематичным.В Unix имя файла - это просто строка, в отличие от DOS, где имя файла составлено из имени и расширения. Таким образом, любое из заданных имен файлов полностью приемлемо.
Но многие программы по-прежнему используют файловые суффиксы, начинающиеся с точки, чтобы различать разные типы файлов, т.е. веб-сервер Apache использует суффиксы для установки правильного типа MIME в заголовках ответов.
источник
Две мысли:
В
Naming Variables, Functions, and Files
разделе стандартов кодирования GNU вы найдете:В то время как IMO говорит «Вы должны использовать,
_
потому что emacs» кажется немного устаревшим, тем не менее, оно есть в их «стандарте».Давайте на минутку предположим, что мы все согласны с тем, что ядро linux является основным и все конечным * в проектах linux, и что используемые здесь соглашения можно считать «стандартными».
grep
-ing источник для ядра Linux, вы найдете следующее:Интересно, что источник для мерзости весит 85% для черточек, 3,8% для подчеркиваний и 11,1% для обеих.
Выбор ясен, дискуссия окончена. ;)
Личное мнение: Я использую тире по эстетическим и ключевым причинам. Если вы работаете в команде, проведите голосование. Но чтобы повторить сказанное, будьте последовательны .
* или "be_all and end_all", если хотите
источник
Символы, которые вы не должны использовать в именах файлов:
Разделители символов, которые вы должны использовать, чтобы облегчить чтение имен:
(В некоторых случаях ":" имеет особое значение, хотя)
источник
/
разделитель пути и ограничитель строки \ 0 (ASCII ноль).Чтобы добавить к тому, что сказали другие, я бы просто сказал, что, хотя в именах файлов допустимы буквы с акцентом и многие специальные символы, они могут вызывать проблемы в любом из следующих сценариев:
...
источник
Придерживайтесь буквенно-цифровых имен файлов. Избегайте пробелов или заменяйте пробелы подчеркиванием (_). Ограничьте знаки препинания в именах файлов точками (.), Символами подчеркивания (_) и дефисами (-). Обычно имена файлов строчные, но я использую 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»
источник
использовать
-
или_
для именования файлов_
для функций.
для расширенийисточник
Я согласен с Дэвидом Онеилом, что тебе следует просто пойти с чем-то.
Но хорошо, если файлы сортируются в одном и том же каталоге, поэтому не номер 0 ..10, а номер 00 ..10.
При использовании дат в именах используйте стандартный формат даты, такой как ISO8601 .
И не бойтесь использовать несколько символов для разделения логических частей в имени. Если вы используете _ (это было 3 _), то позже вы можете упростить регулярные выражения для имен файлов.
Таким образом, ваш пример может быть примерно таким:
Легко читается и легко разбирается со скриптами.
источник
Слова в имени файла могут быть разделены
_
или в-
соответствии с соглашением Unix.Если вы используете
-
, его легче набирать, избавляет вас от нажатия SHIFT. Но так как-
занимает так мало места, это немного трудно для чтения слов по сравнению с_
. Использование_
для разделения слов делает его намного чище, так как_
занимает больше места.В сценариях оболочки и других компьютерных программах
_
используются переменные из нескольких слов, напримерMY_ENVIRONMENT_FILE
. Создание имена файлов использовать ,_
а также сохраняет его последовательноMY_ENVIRONMENT_FILE=~/my_environment_file
.В веб-разработке
-
предпочтительнее для именования файлов. Одна из причин, вероятно, заключается в том, что подчеркивание в веб-ссылках может скрыть подчеркивания и может затруднить ввод текста вручную.В большинстве редакторов, а также на веб-страницах,
this_long_word
могут быть полностью выбраны с двойным щелчком мыши, но неthis-long-word
.источник
-
и_
взять только точно такое же пространство! :)_
выглядит чище, хотя и занимает столько же места, сколько и-
. Я должен был использовать слово «по-видимому». Что касается_
и-
при использовании моноширинных шрифтов, разницу лучше всего объяснить с помощью этой аналогичной картины: evsc.net/v8/wp/wp-content/uploads/2010/09/…Определенно есть стандарт для Linux. Если вы посмотрите на имена файлов в любой системе Linux, они будут в нижнем регистре с тире: / usr / bin / ssh-keygen. Это указано в одном из документов Стандартной базы Linux, который я не могу найти прямо сейчас. Он также указан GNU, который говорит использовать подчеркивания для имен переменных и тире для имен файлов.
источник
Чтобы добавить к тому, что все остальные сказали:
1. Хотя Linux не заботится о расширениях, Windows заботится о них, поэтому убедитесь, что у любого файла, который вы когда-либо планируете предоставить кому-либо, есть соответствующее расширение.
Заголовки с 2 верблюдами, кажется, являются самыми простыми в использовании сценариями, без специальных символов, чтобы беспокоиться о escape-последовательностях.
источник