Чи слід використовувати косу рису в кінці змінних контурів у сценарії оболонки чи ні? [зачинено]

Сьогодні при написанні мого сценарію оболонки.

Питання раптом приходить мені в голову.

Оскільки cd /target_dirі те і cd /target_dir/інше працює.
Чи слід додати косу рису в кінці моїх змінних шляху в сценарій оболонки?
Такі, як LOG_PATH=/data/nginx/logsпроти LOG_PATH=/data/nginx/logs/.

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

Наразі мені справді важко вирішити, який стиль вибрати.
Але я віддав перевагу LOG_PATH=/target_dir/стилю трохи більше.
Тому що, коли я роблю автодоповнення bash, це підскакує мені результат з косою рискою.

Яка ваша думка з цього приводу?

Відповідно до POSIX:

Визначення назви шляху:

Рядок, який використовується для ідентифікації файлу. Він має необов'язкові символи початку <slash> , а потім нульові або більше імен файлів, розділені знаками <slash> . Ім'я шляху може необов'язково містити один або кілька символів, що знаходяться в кінці <slash> . Кілька послідовних символів <косою рискою> вважаються такими ж, як один <косою> , за винятком випадків, коли два точно провідні знаки <коса коса » .

Щоб бути на безпечній стороні, включіть косу рису. Це може призвести до декількох косих рисок при об'єднанні шляхів, але принаймні ви уникнете проблем.

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

Отже, підсумовуючи, це в більшості випадків не має значення, але слід скористатися косою рисою, щоб захистити себе, а також зробити більш очевидним для читача людини те, що ви мали намір зробити в сценарії. Випадковий спостерігач негайно буде впевнений, що змінна посилається на каталог, якщо він закінчується косою рисою, і буде правильно використовувати його, якщо його потрібно змінити.

Ні, не слід. Це додає додатковий непотрібний нахил ( /).

приклад

скажімо, що ви хочете експортувати binкаталог java у свою PATHзмінну,

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

тепер перевірте це,

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

помічайте додаткову косу рису ( /) перед Java, але, на щастя, вона просто працює в такому випадку.