Выполнить скомпилированный исполняемый файл C без ./ [duplicate]

Существует разница между Current Directory и Working Directory, которую вы можете легко найти на google. Вот почему ваш manage.py syncdb не выполнит, как ожидалось.

Current Directory: это каталог, из которого выполняется ваш shell или родительский процесс.

you are right "."  is for current directory.

In UNIX, если у вас есть файл в /data/myfile.out, то вы переходите к своему файлу через имена компонентов, которые разделены forward slash "/", поэтому если "." является вашим текущим каталогом, то если вы хотите получить доступ (выполнить в вашем случае) файл, находящийся внутри вашего текущего каталога, вам нужно будет сказать ./myexecutableFile.o. Если у вас был исполняемый файл в другой папке вашего текущего каталога, вы бы сделали что-то вроде этого ./myFiles/myexecutableFile.o. Надеюсь, вы получили то, что я пытаюсь объяснить.

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

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

echo $PATH

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

PATH=$PATH:.

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

manage.py syncdb

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

Избегайте:

PATH=.:$PATH

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

Только мои два цента.

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

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

./executable

в те, которые вы получаете если вы запустите

executable

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

Проверьте это, выполнив

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

и

whereis executable

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

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

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

./ говорит: «Посмотрите в текущем каталоге для мой сценарий, а не просмотр всех каталогов, указанных в $PATH '.