Должен ли я использовать косую черту в конце пути пути в сценарии оболочки или нет? [закрыто]


11

Сегодня при написании сценария моей оболочки.

Внезапно у меня возникает вопрос.

С тех пор cd /target_dirи то и cd /target_dir/другое работает.
Должен ли я добавить косую черту в конце моих переменных пути в сценарии оболочки?
Такие как LOG_PATH=/data/nginx/logsпротив LOG_PATH=/data/nginx/logs/.

Я провел грубый поиск в Google, но не нашел обсуждения по этому поводу, может быть, это слишком просто?

На данный момент мне очень трудно решить, какой стиль выбрать.
Но я предпочел LOG_PATH=/target_dir/стиль немного больше.
Потому что, когда я делаю автозаполнение с помощью bash, результат выводится с помощью косой черты.

Что вы думаете об этом, почему?



Там нет правила. Оба стиля кодирования имеют некоторые преимущества и недостатки.
andcoz

Ответы:


8

Согласно POSIX:

Определение пути:

Строка, используемая для идентификации файла. Он имеет необязательные начальные символы <slash> , за которыми следуют ноль или более имен файлов, разделенных символами <slash> . Путь может дополнительно содержать один или несколько завершающих символов <slash> . Несколько последовательных символов <slash> считаются такими же, как один <slash> , за исключением случая, когда ровно два ведущих символа <slash> .


@ Интересно, что я могу по- разному отображать в приглашении bash их имена //и /их имена, и pwdя получу другой путь, но их содержимое будет идентичным! Почему?
Zen


1
Потому что bashотслеживает текущий каталог очень наивно, как строку. Он просто добавляет и удаляет из пути эвристически, он не связан с реальной файловой системой. Одним из последствий этого является то, что вы можете перейти в символическую ссылку и вернуться тем же путем (если bash не решил, что это было слишком много, и повторно инициализировал его). Другой - это то, что вы описываете. Вы не должны полагаться на отслеживание оболочки текущего каталога, это ненадежно.
Орион


6

Чтобы быть на безопасной стороне, включите косую черту. Это может привести к множественным наклонам при объединении путей, но, по крайней мере, вы избежите проблем.

Несколько примеров: rsyncтрактует пути по-разному, если включен конечный слеш (он синхронизирует этот каталог вместо создания другого подкаталога). Символические ссылки на каталоги иногда ведут себя неожиданным образом, когда у них нет завершающего слеша - по крайней мере, завершение оболочки запутывается. Вы никогда не знаете, зависит ли вызываемая вами команда / скрипт от проверки на наличие косой черты для какого-то особого поведения. Это может даже спасти вас от перезаписи. Например, если у вас есть файл с именем foo, но вы по ошибке думаете, что это каталог и хотите что-то в нем переместить, он mv bar fooперезапишет файл (потеря данных, потенциальная катастрофа), но mv bar foo/просто будет жаловаться и ничего не делать.

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


2

Нет, не стоит. Это добавляет дополнительную ненужную косую черту ( /).

пример

скажем, вы хотите экспортировать binкаталог Java в вашу PATHпеременную,

export PATH=$PATH:/opt/jre1.7.0_45/bin/

теперь проверь это,

user@host:~$ which java
/opt/jre1.7.0_45/bin//java

обратите внимание на дополнительную косую черту ( /) перед Java, но, к счастью, в таком случае это работает.


Я видел в этой ссылке ответ на 31 голос, в котором автор считает, что мы должны добавить косую черту. Я не совсем понимаю. stackoverflow.com/questions/980255/…
дзен

@Zen, да, я проверил это, это было в первом комментарии вашего вопроса. Благодарю.
Арнаб

6
Лучше две косые черты, чем нет. Этот уродливый, но безопасный ... другой вариант намного хуже и может быть опасным.
Орион
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.