Чи є різниця між шляхами "файл" і "./file"?


12

Як говорить заголовок, чи є різниця для файлових систем * NIX? наприклад ls fileіls ./file


1
Ви можете запитати unix.stackexchange.com - поки що у всіх відповідях є гарна інформація, але жоден із насправді не відчуває такої відповіді.
Роб Старлінг

Відповіді:


14

Я не збожеволів на пояснення SmallLoanOf1M. Це технічно правильно, але відповідає таким чином, що не відповідає прикладу використання у питанні.

Отже, для прикладу, ось одна важлива відмінність між двома питаннями: "файл" та "./file"

Що робити, якщо файл названий символом, який розбирається оболонкою? Особливо щодо символів, інтерпретованих командою.

Зокрема, символ "тире": "-". Але інші символи мають значення для оболонки.

Приклад. Мій файл назвали "-dingle"

Спробуйте перерахувати файл:

ls -dingle
# ls -dingle
ls: invalid option -- 'e'

Ще гірше, що якщо файл назвав " -rf rmbomb *"? Тепер спробуйте її видалити

rm "-rf rmbomb *"

Я навіть не збираюся наводити цей приклад, але, сподіваюся, ви отримаєте ідею.

Тож як ви перелічити файл, на якому розміщено тире? Використовуйте ./спереду.

# ls ./-dingle
./-dingle

Дітто для rm


Це правильний спосіб обробляти деякі файли з непарними іменами, і моя відповідь не вважала такі файли. Замість цього можна також використовувати буквальний текст у всіх наведених вище прикладах у вигляді зворотної косої лінії, що передує непарним символам, включаючи пробіли, зазначені вище. Прикладом цього може бути так: ls \-dingleабо ls \-rf\ rmbomb\ \*. Це може бути хорошим способом гарантувати, що будь-який заданий набір команд є принаймні послідовним, оскільки вказівка ./перед тим, як ім'я не вийде з символів після ./.
Спулер

2
Буває так, що, оскільки вхідні файли виводяться за допомогою оболонки, а не команда, а парами аналізуються командою, втеча або цитується - нічого корисного не робить.
Дьюї Морган

2
Ви здаєтеся, що rm "-rf rmbomb *"це насправді зробить щось погане, а не просто rmнадрукує помилку. Це небезпечно лише в тому випадку, якщо ви забудете процитувати ім'я файлу, тому розбиття слів відбувається. (особливо в скрипті оболонки, де ви працюєте rm $fileзамість rm "$file". Але в цьому випадку *розширення не розгортається, оскільки глобальне розширення не відбувається на вмісті змінного розширення. Якщо ви цього хочете, вам знадобиться eval.) У будь-якому випадку, якщо ваш сценарій розбиває назви файлів перед переходом до rm, я б створив файл, який називається space -rf .або щось подібне, тому rm ./$iне допомагає.
Пітер Кордес

1
До речі, власне повідомлення про помилку - rm: invalid option -- ' 'це коли він намагається інтерпретувати пробіл -rfяк односимвольний перемикач, тому що це частина одного аргументу. (І так, я запустив це всередині порожнього каталогу на всякий випадок, якщо я щось пропустив, і це було насправді небезпечно: P)
Пітер Кордес

2
@PeterCordes: Розрізання слів і глобалізація DOES виникають на результатах розширення без змін котируемих змінних і підстановки команд, якщо не придушується відповідно IFS=''і -fвідповідно. Більш рідкісний приклад - це awkтрактування операнда (окрім першого операнда, що є сценарієм), що має форму foo=barяк завдання виконувати, але ./foo=barяк файл для читання.
dave_thompson_085

7

Так.

Видавши fileв командному рядку, BASH буде шукати вашу змінну середовища $ PATH для файлу з цим іменем. Якщо файл знаходиться в каталозі у вашій змінній $ PATH, його не буде знайдено.

.означає поточний каталог. ./означає в поточному каталозі, відносно. Це еквівалент сказати щось на зразок /home/sheogorath/shivering/isles.imgпід ./isles.imgчас виклику під час роботи в /home/sheogorath/shivering/каталозі.

Таким чином, зазвичай використовується для виконання файлів у вашому робочому каталозі "на місці".

EDIT: У вашому прикладі lsвикликається оболонка і знайдеться за допомогою змінної шляху. Його аргумент буде оброблено у вашому робочому каталозі, яким би це не було. Оскільки це за замовчуванням для ls, ви не побачите різниці між специфікацією fileта явним зазначенням, ./fileоскільки вони обоє вказують на ваш поточний каталог.

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


1
Це баш, але мені було цікаво взагалі роздільну здатність
Сергій Алаєв

1
Це так, як будь-яка оболонка, яку я коли-небудь чув про твори. BASH - це лише найпоширеніший.
Скулер

4
$ PATH доречний лише для команд і не має нічого спільного з аргументами імен файлів, які слідують за командою, такою, як lsзазначено в первинному запитанні. Тобто чим більше різниця між refferencing на відносний шлях ( по відношенню до поточного робочого каталогу) Тобто ../../dir/filenameі абсолютний шлях /path/to/dir/filename
HBruijn

1
+1 для Sheogorath ... і правильна відповідь.
Корі Огберн

1
Якщо вони аргументують команду, яка намагається знайти файли у робочому каталозі за замовчуванням, вони будуть однаковими. Таким чином, оскільки lsвони завжди будуть однаковим шляхом, один визначений більш чітко, ніж інший. Не всі команди поводяться таким чином при обробці аргументів, але більшість це робить.
Скулер
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.