Должна ли переменная пути к каталогу заканчиваться косой чертой?

Question 1

При определении пути к каталогу как переменной или константы должен ли он заканчиваться косой чертой в конце? Что такое условность?

pwdв Unix показывает текущий каталог без косой черты в конце, в то время как вкладка, завершенная из, cd /var/www/apps/включает в себя завершающую косую черту, что оставило меня неуверенным.

Question 2

Я не использую косую черту в конце, когда, например, определяю каталог для хранения файлов. Это потому, что я буду использовать его как

$store_file = "$store_path/$file_id";

Я всегда буду добавлять косую черту в конце перед использованием переменной, которая должна содержать путь к каталогу. Я думаю, что лучше всегда добавлять один, чем задаваться вопросом, включен ли завершающий слэш.

Question 3

Я использую косую черту в конце, потому что:

«Если он заканчивается косой чертой, это каталог. Если нет, это файл». легко запомнить.
По крайней мере, в операционных системах, которые я обычно использую, удвоение косой черты не вызывает проблем, а пропуск косой черты вызывает большие. Следовательно, безопаснее всего поместить косую черту в переменную и использовать "$ path / $ file" при ее использовании.

Question 4

Я знаю, что ему 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

Question 5

Да, должно, так как:

Путь + имя файла = полное расположение файла.

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

Question 6

Всякий раз, когда я сохраняю пути к каталогам или возвращаю их из API, я стараюсь придерживаться соглашения о сохранении косой черты в конце. Это позволяет избежать всей двусмысленности "это файл или каталог".

Приложение :
это не предназначено для замены использования методов, которые допускают либо завершающую косую черту, либо ее отсутствие. Даже используя это соглашение, я все еще использую Path.Combine(...)подобные методы.

Question 7

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

Теперь, если по какой-то причине путь, ведущий к файлу, отсутствует при объединении строк, вы получите что-то вроде того, /filenameчто не просто файл, а абсолютный путь из корневого каталога (где бы он ни находился в этом контексте) .

Вот почему я заканчиваю пути косой чертой и сохраняю файлы как файлы.

Question 8

Я знаю, что это старая ветка, но я подумал, что поделюсь тем, чем занимаюсь. Если возможно, я обычно разрешаю и то, и другое и делаю что-то вроде этого (если бы это был PHP):

$fullPath = rtrim($directory, '/') . '/filename.txt');

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

Question 9

В php, поскольку функция dirname (__ FILE __) возвращает имя каталога без косой черты в конце. Я склонен придерживаться этого соглашения.

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

Итог: не используйте завершающую косую черту, так как имя каталога (..) не используется.

// PHP Example
dirname(__FILE__); // returns c:\my\directory without a trailing slash, so stick to it!

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

Question 10

Я обычно просто добавляю косую черту в конце, поскольку я, скорее всего, буду использовать этот каталог для добавления / извлечения файлов ...

Что касается веб-ссылок, это может фактически повысить производительность, оставив косую черту в конце

http://www.netmechanic.com/news/vol4/load_no11.htm

Question 11

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

Question 12

В любом случае я никогда не видел твердой конвенции.

Однако совершенно уверен, что что бы вы ни выбрали, кто-то другой будет на 100% уверен, что должно быть наоборот. Итак, лучшая идея - терпеть все, что установлено в любом случае.

В мире .NET Path.Combine () дает вам способ справиться с этим - есть эквиваленты в других средах, начиная с файлов cmd.

Question 13

Думаю, это один из тех редких случаев, когда правильный теоретический и практический ответ различаются.

Кажется, что ответ @Karl Wilbur наверняка верен в теоретическом смысле, так как вы должны уметь отличать ссылку на сам узел каталога от содержимого каталога.

Но на практике я утверждаю, что правильный ответ - противоположный:

Самая важная причина состоит в том, что вы можете с уверенностью сказать, что путь /home/FSObjectX/к папке /home/FSObjectXявляется неоднозначным. Никто не может сказать, является ли это файлом папки.
По возможности спецификации всегда должны быть точными и однозначными.
В подавляющем большинстве случаев вы всегда будете ссылаться на содержимое папки, а не на сам узел dir.
В тех редких случаях, когда вы действительно это делаете, это можно легко обработать в коде, удалив любой необязательный конечный разделитель dir.
Использование двойных разделителей-разделителей не повредит, хотя отсутствие одного наверняка.
Теоретически это плохой аргумент, так как вы не должны кодировать «случайно», но на практике ошибки случаются, и, возможно, использование завершающего dir-sep может привести к меньшему количеству ошибок времени выполнения у конечного пользователя.

Читая эту интересную ветку, я не нашел никаких недостатков в использовании завершающего dir-sep, только то, что это неверно в теоретическом смысле. Или я что-то упустил?

Answer 1

При определении пути к каталогу как переменной или константы должен ли он заканчиваться косой чертой в конце? Что такое условность?

pwdв Unix показывает текущий каталог без косой черты в конце, в то время как вкладка, завершенная из, cd /var/www/apps/включает в себя завершающую косую черту, что оставило меня неуверенным.

Answer 2

24

Я не использую косую черту в конце, когда, например, определяю каталог для хранения файлов. Это потому, что я буду использовать его как

$store_file = "$store_path/$file_id";

Я всегда буду добавлять косую черту в конце перед использованием переменной, которая должна содержать путь к каталогу. Я думаю, что лучше всегда добавлять один, чем задаваться вопросом, включен ли завершающий слэш.

Йохан Содерберг
источник

29

Отсутствие косой черты в конце означает, что неясно, является ли путь в $ store_path файлом или каталогом. "/ tmp / store_data" это файл или каталог?

Дарвин

4

При использовании чего-то вроде функции PHP realpath () она не выводит завершающую косую черту. Ваша система и инструменты могут диктовать ваше соглашение.

jmbertucci

10

Наличие нескольких косых черт в любом месте обычно интерпретируется как один косой чертой. Так что у вас может быть что-то вроде, '///' + $root + '//' + $file + '/'и это не имеет значения. Хотя наличие завершающей косой черты - это хороший способ определить, является ли путь файлом или каталогом, лучше добавить к таким путям, '/' + $rootа не $root + '/'потому, что вы не можете быть уверены, что добавляемый путь имеет завершающую косую черту , но вы можете быть относительно уверены, что в большинстве сред несколько косых черт будут интерпретироваться как один.

Xtrinity

3

@MatthewSlyman, Я хотел сказать, что все ожидают, что это /tmp/store_data/будет каталог, в то время как неясно, что это за тот же путь без косой черты/tmp/store_data

Дарвин

6

Проблема с этим: если переменная не существует, она такая же, как пустая, и rm -rf $foo/$barможет оканчиваться наrm -rf /

12431234123412341234123 01

Answer 3

29

Отсутствие косой черты в конце означает, что неясно, является ли путь в $ store_path файлом или каталогом. "/ tmp / store_data" это файл или каталог?

Дарвин

Answer 4

4

При использовании чего-то вроде функции PHP realpath () она не выводит завершающую косую черту. Ваша система и инструменты могут диктовать ваше соглашение.

jmbertucci

Answer 5

10

Наличие нескольких косых черт в любом месте обычно интерпретируется как один косой чертой. Так что у вас может быть что-то вроде, '///' + $root + '//' + $file + '/'и это не имеет значения. Хотя наличие завершающей косой черты - это хороший способ определить, является ли путь файлом или каталогом, лучше добавить к таким путям, '/' + $rootа не $root + '/'потому, что вы не можете быть уверены, что добавляемый путь имеет завершающую косую черту , но вы можете быть относительно уверены, что в большинстве сред несколько косых черт будут интерпретироваться как один.

Xtrinity

Answer 6

3

@MatthewSlyman, Я хотел сказать, что все ожидают, что это /tmp/store_data/будет каталог, в то время как неясно, что это за тот же путь без косой черты/tmp/store_data

Дарвин

Answer 7

6

Проблема с этим: если переменная не существует, она такая же, как пустая, и rm -rf $foo/$barможет оканчиваться наrm -rf /

12431234123412341234123 01

Answer 8

102

Я использую косую черту в конце, потому что:

«Если он заканчивается косой чертой, это каталог. Если нет, это файл». легко запомнить.
По крайней мере, в операционных системах, которые я обычно использую, удвоение косой черты не вызывает проблем, а пропуск косой черты вызывает большие. Следовательно, безопаснее всего поместить косую черту в переменную и использовать "$ path / $ file" при ее использовании.

Дэйв Шерохман
источник

9

Путь к каталогу можно отличить от пути к файлу, только если путь к каталогу имеет косую черту в конце.

Дарвин

4

Множественные косые черты эквивалентны одной косой черте, если путь не начинается с двойной косой черты. См. Unix.stackexchange.com/questions/1910/…

jdh8 02

4

Кроме того, добавление косой черты в конце переменной vaariable позволяет использовать «$ path $ file» вместо «$ path / $ file», что позволяет использовать пустой $ path, то есть текущий рабочий каталог. Но никогда не используйте обратную косую черту вместо косой черты.

fantastory

Дескрипторы файлов тоже полезны

Франческо Гуалацци

@ jdh8 Даже если путь начинается с двойной косой черты, он все равно должен быть эквивалентен одной косой черте. Хотя это может измениться от реализации к реализации. Стандарты unix заявляют, что

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.

по большей части наблюдается, что двойная косая черта обычно интерпретируется как одинарная косая черта в общих реализациях.

Xtrinity

Answer 9

9

Путь к каталогу можно отличить от пути к файлу, только если путь к каталогу имеет косую черту в конце.

Дарвин

Answer 10

4

Множественные косые черты эквивалентны одной косой черте, если путь не начинается с двойной косой черты. См. Unix.stackexchange.com/questions/1910/…

jdh8 02

Answer 11

4

Кроме того, добавление косой черты в конце переменной vaariable позволяет использовать «$ path $ file» вместо «$ path / $ file», что позволяет использовать пустой $ path, то есть текущий рабочий каталог. Но никогда не используйте обратную косую черту вместо косой черты.

fantastory

Answer 12

Дескрипторы файлов тоже полезны

Франческо Гуалацци

Answer 13

@ jdh8 Даже если путь начинается с двойной косой черты, он все равно должен быть эквивалентен одной косой черте. Хотя это может измениться от реализации к реализации. Стандарты unix заявляют, что

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.

по большей части наблюдается, что двойная косая черта обычно интерпретируется как одинарная косая черта в общих реализациях.

Xtrinity

Answer 14

Я знаю, что ему 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

Answer 15

Отличный ответ. Я склонен был использовать этот подход, но никогда не мог полностью объяснить, почему. Это единственный ответ, который ее решает.

wardw

Answer 16

4

Это корень /ломает шаблон. И если бы вы начали рассуждение отсюда (рекурсивно), вы могли бы затем перейти к противоречиям, которые могут лежать в основе расходящихся практик (как видно из ответов здесь). Но как только вы примете это как исключение, все остальное подойдет.

wardw

Answer 17

Понимаю. Немного поигрался с dirname. Если вы намерены явно сохранить каталог в пути, завершите путь знаком «/.», Где точка представляет текущий каталог.

TamusJRoyce

Answer 18

2

@wardw вы можете думать о корневом каталоге как о пустой строке, а «/» - это пустая строка, за которой следует косая черта, что означает «содержимое корневого каталога».

bobpaul

Answer 19

1

За этот ответ следует проголосовать больше. См. Также раздел " Ошибочные представления о пути к файлам" в Wiki.

john cj

Answer 20

Да, должно, так как:

Путь + имя файла = полное расположение файла.

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

Answer 21

5

.. и неспособность принять это во внимание означает, что вы, возможно, нечаянно возитесь с /, и в этом заключается безумие

JustJeff

Answer 22

Всякий раз, когда я сохраняю пути к каталогам или возвращаю их из API, я стараюсь придерживаться соглашения о сохранении косой черты в конце. Это позволяет избежать всей двусмысленности "это файл или каталог".

Приложение :
это не предназначено для замены использования методов, которые допускают либо завершающую косую черту, либо ее отсутствие. Даже используя это соглашение, я все еще использую Path.Combine(...)подобные методы.

Answer 23

python:os.path.join(dir, subdir_or_file)

IceArdor

Answer 24

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

Теперь, если по какой-то причине путь, ведущий к файлу, отсутствует при объединении строк, вы получите что-то вроде того, /filenameчто не просто файл, а абсолютный путь из корневого каталога (где бы он ни находился в этом контексте) .

Вот почему я заканчиваю пути косой чертой и сохраняю файлы как файлы.

Answer 25

1

Альтернативой здесь является выражение вашего имени файла как ./filename. Но в целом код, объединяющий пути, должен делать это правильно, а не делать предположений в любом случае.

wardw

Answer 26

Я знаю, что это старая ветка, но я подумал, что поделюсь тем, чем занимаюсь. Если возможно, я обычно разрешаю и то, и другое и делаю что-то вроде этого (если бы это был PHP):

$fullPath = rtrim($directory, '/') . '/filename.txt');

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

Answer 27

В php, поскольку функция dirname (__ FILE __) возвращает имя каталога без косой черты в конце. Я склонен придерживаться этого соглашения.

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

Итог: не используйте завершающую косую черту, так как имя каталога (..) не используется.

// PHP Example
dirname(__FILE__); // returns c:\my\directory without a trailing slash, so stick to it!

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

Answer 28

2

Исключение: dirname ('/ test') = '/' - вместо того, чтобы возвращать пустую строку, dirname в этом случае возвращает одинарную косую черту! См. Примечания здесь .

Мэтью Слайман,

Answer 29

Я обычно просто добавляю косую черту в конце, поскольку я, скорее всего, буду использовать этот каталог для добавления / извлечения файлов ...

Что касается веб-ссылок, это может фактически повысить производительность, оставив косую черту в конце

http://www.netmechanic.com/news/vol4/load_no11.htm

Answer 30

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

Answer 31

В любом случае я никогда не видел твердой конвенции.

Однако совершенно уверен, что что бы вы ни выбрали, кто-то другой будет на 100% уверен, что должно быть наоборот. Итак, лучшая идея - терпеть все, что установлено в любом случае.

В мире .NET Path.Combine () дает вам способ справиться с этим - есть эквиваленты в других средах, начиная с файлов cmd.

Answer 32

Думаю, это один из тех редких случаев, когда правильный теоретический и практический ответ различаются.

Кажется, что ответ @Karl Wilbur наверняка верен в теоретическом смысле, так как вы должны уметь отличать ссылку на сам узел каталога от содержимого каталога.

Но на практике я утверждаю, что правильный ответ - противоположный:

Самая важная причина состоит в том, что вы можете с уверенностью сказать, что путь /home/FSObjectX/к папке /home/FSObjectXявляется неоднозначным. Никто не может сказать, является ли это файлом папки.
По возможности спецификации всегда должны быть точными и однозначными.
В подавляющем большинстве случаев вы всегда будете ссылаться на содержимое папки, а не на сам узел dir.
В тех редких случаях, когда вы действительно это делаете, это можно легко обработать в коде, удалив любой необязательный конечный разделитель dir.
Использование двойных разделителей-разделителей не повредит, хотя отсутствие одного наверняка.
Теоретически это плохой аргумент, так как вы не должны кодировать «случайно», но на практике ошибки случаются, и, возможно, использование завершающего dir-sep может привести к меньшему количеству ошибок времени выполнения у конечного пользователя.

Читая эту интересную ветку, я не нашел никаких недостатков в использовании завершающего dir-sep, только то, что это неверно в теоретическом смысле. Или я что-то упустил?

Answer 33

на практике вы обнаружите, что правильное ожидание - не содержать завершающей косой черты. Просто посмотрите на каждый используемый вами инструмент, написанный компетентными разработчиками.

Карл Уилбур

Должна ли переменная пути к каталогу заканчиваться косой чертой?

Ответы: