it-swarm.com.ru

Зачем вам нужно ./ (точка-косая черта) перед именем исполняемого файла или скрипта, чтобы запустить его в bash?

При запуске сценариев в bash я должен сначала написать ./:

$ ./manage.py syncdb

Если я этого не сделаю, я получаю сообщение об ошибке:

$ manage.py syncdb
-bash: manage.py: command not found

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

Я также не понимаю, почему мне не нужен ./ при запуске приложений, таких как:

user:/home/user$ cd /usr/bin
user:/usr/bin$ git

(который работает без ./)

260
Dan Abramov

Потому что в Unix обычно текущий каталог не находится в $PATH.

Когда вы набираете команду, оболочка ищет список каталогов, как указано в переменной PATH. Текущий каталог не в этом списке.

Причиной отсутствия текущего каталога в этом списке является безопасность.

Допустим, вы являетесь пользователем root и зайдите в каталог другого пользователя и введите sl вместо ls. Если текущий каталог находится в PATH, оболочка попытается выполнить программу sl в этом каталоге (поскольку другой sl нет). Эта программа sl может быть вредоносной.

Он работает с ./, потому что POSIX указывает что имя команды, которое содержит /, будет использоваться непосредственно в качестве имени файла, подавляя поиск в $PATH. Вы могли бы использовать полный путь для того же эффекта, но ./ короче и проще для написания.

РЕДАКТИРОВАТЬ

Та часть sl была просто примером. Каталоги в PATH ищутся последовательно, и при совпадении выполняется программа. Таким образом, в зависимости от того, как выглядит PATH, ввода нормальной команды может быть или не быть достаточно для запуска программы в текущем каталоге.

283
cnicutar

Когда bash интерпретирует командную строку, он ищет команды в местах, описанных в переменной среды $PATH. Чтобы увидеть это введите:

echo $PATH

У вас будет несколько путей, разделенных двоеточиями. Как вы увидите, текущий путь . обычно отсутствует в $PATH. Таким образом, Bash не может найти вашу команду, если она находится в текущем каталоге. Вы можете изменить это, имея:

PATH=$PATH:.

Эта строка добавляет текущий каталог в $PATH, так что вы можете сделать:

manage.py syncdb

Это не рекомендуется, так как имеет проблему с безопасностью, плюс у вас может быть странное поведение, так как . зависит от каталога, в котором вы находитесь :)

Избегайте:

PATH=.:$PATH

Как вы можете "замаскировать" какую-то стандартную команду и открыть дверь для нарушения безопасности :)

Просто мои два цента.

48
neuro

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

./ говорит: "ищите в текущем каталоге мой скрипт, а не просматривайте все каталоги, указанные в $PATH".

39
mdm

Когда вы включаете "." по сути, вы даете "полный путь" исполняемому скрипту bash, поэтому вашей командной оболочке не нужно проверять переменную PATH. Без '.' ваш Shell будет искать в вашей переменной PATH (которую вы можете увидеть, выполнив echo $PATH, чтобы увидеть, находится ли введенная вами команда в какой-либо из папок в вашем PATH. Если это не так (как в случае с manage.py), она говорит файл не может быть найден. Включать текущий каталог в PATH считается плохой практикой, что достаточно хорошо объяснено здесь: http://www.faqs.org/faqs/unix-faq/faq /part2/section-13.html

4
Mark Drago

В * nix, в отличие от Windows, текущий каталог обычно отсутствует в переменной $PATH. Таким образом, текущий каталог не ищется при выполнении команд. Вам не нужен ./ для запуска приложений, потому что эти приложения есть в вашем $ PATH; скорее всего, они находятся в /bin или /usr/bin.

2
Anomie

На этот вопрос уже есть несколько отличных ответов, но я хотел бы добавить, что если ваш исполняемый файл находится в переменной PATH, и вы получаете очень разные результаты при запуске

./executable

к тем, которые вы получаете, если вы бежите

executable

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

Проверьте это, запустив

какой исполняемый файл

а также

whereis executable

Это исправило мои проблемы ... У меня было три версии исполняемого файла, только одна из которых была скомпилирована правильно для среды.

1
KR_Henninger

Когда скрипт не находится в пути, это необходимо сделать. Для получения дополнительной информации читайте http://www.tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_01.html

0
Gayan Hewa