При определении пути к каталогу как переменной или константы должен ли он заканчиваться косой чертой в конце? Что такое условность?
pwdв Unix показывает текущий каталог без косой черты в конце, в то время как вкладка, завершенная из, cd /var/www/apps/включает в себя завершающую косую черту, что оставило меня неуверенным.
Ответы:
Я не использую косую черту в конце, когда, например, определяю каталог для хранения файлов. Это потому, что я буду использовать его как
$store_file = "$store_path/$file_id";
Я всегда буду добавлять косую черту в конце перед использованием переменной, которая должна содержать путь к каталогу. Я думаю, что лучше всегда добавлять один, чем задаваться вопросом, включен ли завершающий слэш.
'///' + $root + '//' + $file + '/'и это не имеет значения. Хотя наличие завершающей косой черты - это хороший способ определить, является ли путь файлом или каталогом, лучше добавить к таким путям, '/' + $rootа не $root + '/'потому, что вы не можете быть уверены, что добавляемый путь имеет завершающую косую черту , но вы можете быть относительно уверены, что в большинстве сред несколько косых черт будут интерпретироваться как один.
/tmp/store_data/будет каталог, в то время как неясно, что это за тот же путь без косой черты/tmp/store_data
rm -rf $foo/$barможет оканчиваться наrm -rf /
Я использую косую черту в конце, потому что:
«Если он заканчивается косой чертой, это каталог. Если нет, это файл». легко запомнить.
По крайней мере, в операционных системах, которые я обычно использую, удвоение косой черты не вызывает проблем, а пропуск косой черты вызывает большие. Следовательно, безопаснее всего поместить косую черту в переменную и использовать "$ path / $ file" при ее использовании.
A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner, although more than two leading slashes shall be treated as a single slash.по большей части наблюдается, что двойная косая черта обычно интерпретируется как одинарная косая черта в общих реализациях.
Я знаю, что ему 10 лет, но я хотел бросить свои очень самоуверенные 0,02 доллара.
Нет. Нет. Абсолютно нет.
Мы говорим о системе Unix. Что касается самого каталога, это такой же узел, как и любой другой. При обращении к каталогу в его имени никогда не должно быть неэкранированной косой черты (ссылка:dirname , pwd, ~, echo $HOME, echo $PATH, выход из lsдр).
Обращаясь к содержимому каталога, то вам нужен слэш. То есть ls /home/karl/более уместно, чем ls /home/karl(FTR, я почти всегда делаю последнее, потому что ... ну, ленивый).
При использовании переменной, содержащей каталог, для создания полного пути к файлу, вы всегда ожидаете включения косой черты (т.е., e:) cp ${HOME}/test ${OTHER_DIR}/.
это ожидается , что каталог не заканчивается косой чертой. Ожидание того, что каталог заканчивается косой чертой, неверно. Таким образом, добавление косой черты в конце значения *_DIRпеременной разрушит ожидания.
Что касается завершения вкладки, здесь ожидается, что вы собираетесь в этот каталог. Таким образом, добавление вкладок поможет вам попасть в этот каталог, чтобы вы могли сделать следующий выбор на основе его содержимого.
(ссылка из комментариев: Заблуждения о пути к файлам , со Talk:Path_(computing)страницы Википедии . Спасибо, Джон Си )
Стоит отметить, что то, что это неправильно, не означает, что инструменты / пакеты / библиотеки никогда этого не делают. Очень часто такие вещи добавляют косую черту в конце, когда ее не должно быть. Поэтому, как предложили Беван и Пол Ф. , при использовании сторонних инструментов лучше всего удалить любые завершающие косые черты, которые могут присутствовать в именах каталогов.
Иноды Unix
Inode (индексный узел) - это структура данных в файловой системе в стиле Unix, которая описывает объект файловой системы, такой как файл или каталог.
- https://en.wikipedia.org/wiki/Inode
Стандарт иерархии файловой системы
ВСтандарт для Unix файловой системы (Filesystem Hierarchy Standard, AKA FHS) ясно показывает , что каталоги не мыслится как имеющий слэш, а скорее содержимое каталога начинается с косым черты (единственное исключение из этого правила, /потому что мы не будем называть корень файловой системы, используя пустую строку ... и в любом случае никогда не следует создавать там файлы.)
- http://www.pathname.com/fhs/pub/fhs-2.3.html
- https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
/ломает шаблон. И если бы вы начали рассуждение отсюда (рекурсивно), вы могли бы затем перейти к противоречиям, которые могут лежать в основе расходящихся практик (как видно из ответов здесь). Но как только вы примете это как исключение, все остальное подойдет.
Да, должно, так как:
Путь + имя файла = полное расположение файла.
Итак, косая черта между последним каталогом и именем файла должна быть либо в конце пути, либо в начале имени файла. Добавление к именам файлов префикса / означает, что вам необходимо принять это во внимание, если вы просто хотите открыть файл (т.е. если вы предполагаете, что неквалифицированное имя файла находится в текущем рабочем каталоге).
Всякий раз, когда я сохраняю пути к каталогам или возвращаю их из API, я стараюсь придерживаться соглашения о сохранении косой черты в конце. Это позволяет избежать всей двусмысленности "это файл или каталог".
Приложение :
это не предназначено для замены использования методов, которые допускают либо завершающую косую черту, либо ее отсутствие. Даже используя это соглашение, я все еще использую Path.Combine(...)подобные методы.
os.path.join(dir, subdir_or_file)
Возможно, вам стоит подумать о том, что ваше решение будет значить для файлов. Если вы не включите завершающую косую черту в конце имени каталога, вам придется добавить ее в начало имени файла .
Теперь, если по какой-то причине путь, ведущий к файлу, отсутствует при объединении строк, вы получите что-то вроде того, /filenameчто не просто файл, а абсолютный путь из корневого каталога (где бы он ни находился в этом контексте) .
Вот почему я заканчиваю пути косой чертой и сохраняю файлы как файлы.
./filename. Но в целом код, объединяющий пути, должен делать это правильно, а не делать предположений в любом случае.
Я знаю, что это старая ветка, но я подумал, что поделюсь тем, чем занимаюсь. Если возможно, я обычно разрешаю и то, и другое и делаю что-то вроде этого (если бы это был PHP):
$fullPath = rtrim($directory, '/') . '/filename.txt');
Таким образом, если каталог определен в файле конфигурации, не имеет значения, будет ли следующий человек, который изменит его, включить косую черту в конце или нет.
В php, поскольку функция dirname (__ FILE __) возвращает имя каталога без косой черты в конце. Я склонен придерживаться этого соглашения.
В противном случае использование косой черты в конце имени каталога будет противоречить способу работы dirname (..), и тогда вы застрянете с обработкой двух случаев, так как вы не знаете, получено ли имя каталога из имени каталога (.. ) или содержимое, определенное с помощью косой черты в конце.
Итог: не используйте завершающую косую черту, так как имя каталога (..) не используется.
// PHP Example
dirname(__FILE__); // returns c:\my\directory without a trailing slash, so stick to it!
Для других языков проверьте функцию, которая извлекает имя пути, и посмотрите, использует ли она завершающую косую черту или нет, а затем придерживайтесь соглашения языка.
Я обычно просто добавляю косую черту в конце, поскольку я, скорее всего, буду использовать этот каталог для добавления / извлечения файлов ...
Что касается веб-ссылок, это может фактически повысить производительность, оставив косую черту в конце
В любом случае я никогда не видел твердой конвенции.
Однако совершенно уверен, что что бы вы ни выбрали, кто-то другой будет на 100% уверен, что должно быть наоборот. Итак, лучшая идея - терпеть все, что установлено в любом случае.
В мире .NET Path.Combine () дает вам способ справиться с этим - есть эквиваленты в других средах, начиная с файлов cmd.
Думаю, это один из тех редких случаев, когда правильный теоретический и практический ответ различаются.
Кажется, что ответ @Karl Wilbur наверняка верен в теоретическом смысле, так как вы должны уметь отличать ссылку на сам узел каталога от содержимого каталога.
Но на практике я утверждаю, что правильный ответ - противоположный:
Самая важная причина состоит в том, что вы можете с уверенностью сказать, что путь /home/FSObjectX/к папке /home/FSObjectXявляется неоднозначным. Никто не может сказать, является ли это файлом папки.
По возможности спецификации всегда должны быть точными и однозначными.
В подавляющем большинстве случаев вы всегда будете ссылаться на содержимое папки, а не на сам узел dir.
В тех редких случаях, когда вы действительно это делаете, это можно легко обработать в коде, удалив любой необязательный конечный разделитель dir.
Использование двойных разделителей-разделителей не повредит, хотя отсутствие одного наверняка.
Теоретически это плохой аргумент, так как вы не должны кодировать «случайно», но на практике ошибки случаются, и, возможно, использование завершающего dir-sep может привести к меньшему количеству ошибок времени выполнения у конечного пользователя.
Читая эту интересную ветку, я не нашел никаких недостатков в использовании завершающего dir-sep, только то, что это неверно в теоретическом смысле. Или я что-то упустил?