Когда я пытался запустить свой .sh файл в Redhat, используя ./test.sh
Я получаю сообщение об ошибке
[test@tester unix_scripts]$ ./test.sh
: No such file or directory
[test@tester unix_scripts]$
Я также установил разрешение файла с chmod 777 test.sh
все та же ошибка
Кто-нибудь может мне помочь?
На самом деле проблема заключалась в том, что сценарий, который я использовал, был создан в dos, поэтому я преобразовал свой сценарий в unix с помощью команды dos2unix. Спасибо всем за вашу ценную помощь.
Возможно, вы забыли указать в первой строке вашего скрипта:
#!/bin/bash
например:
#!/bin/bash
echo Hello World
Если вы попробуете простой сценарий оболочки, как в приведенном выше примере hello world? работает или нет?
Кстати: вы уверены в контексте SELinux?
Что значит: getenforce сказать?
Что значит: ls -l test.sh сказать?
Мой лучший совет - сначала попробуйте очень простой сценарий, чтобы вы могли проверить каждую среду и поведение контекста.
Дважды проверьте, что вы находитесь в правильном каталоге (вы можете просмотреть, что находится в каталоге, набрав «ls»), а имя файла - «test.sh». Вы также можете попробовать:
[test@tester unix_scripts]$ sh test.sh
Находится ли test.sh в каталоге unix_scripts?
Есть ли в test.sh файл или каталог, который не существует? Потому что ошибка может исходить из самого скрипта, а не из-за выполнения скрипта ...
Да, должно быть #! (грохот!) :)
Можете ли вы опубликовать результаты следующих команд, выполненных в каталоге, в котором находится ваш скрипт?
ls -l
cat test.sh
Ты используешь ш или трепать? (т.е. какова первая строка вашего скрипта?)
Если вы используете #! / bin / sh, тогда вам нужно убедиться, что / bin / sh существует (введите какой ш)
Возможно, вам придется попробовать #! / bin / bash или другую оболочку, если / bin / sh не установлен.
Пытаться getenforce. Если это принудительно, то selinux включен и ваш скрипт может потребоваться для запуска в другом контексте.
Если getenforce возвращает принудительное выполнение, затем проверьте dmesg, / var / log / message /var/log/audit/audit.log или где бы то ни было, на вашем хосте selinux входит в систему, чтобы найти точную проблему.
Или просто попробуйте настроить сценарий в тот же контекст, что и другой запущенный сценарий.
Чтобы увидеть контекст файлов, используйте ls -lZ.
Или попробуйте
chcon --reference=/script/that/will/work /script/that/wont/work
Возможно, проверьте страницу руководства chcon, я не уверен на 100% в синтаксисе --reference.
Добавление хэшбэга в ваш скрипт не изменит того, что нужно для его запуска. Вам нужно либо сделать его исполняемым (chmod + x test.sh), а затем запустить (./test.sh), либо вы можете вызвать его как аргумент оболочки (sh test.sh).
Вы также можете поместить скрипт в любое место из переменной $ PATH (например, ~ / bin /, / usr / local / bin /), и, если он исполняемый, вы можете запустить его из любого места, не ссылаясь на его местоположение (test.sh) .
Если сценарий запускается без аргумента оболочки, он по умолчанию запускается в любой оболочке, которую вы используете в данный момент. Который здесь важен хэшбанг ... если вы хотите убедиться, что он запускается как сценарий bash, даже если пользователь использует tcsh, ksh или что-то еще, вы помещаете #! / bin / bash в качестве первой строки сценария .
шаг 1 - проверьте наличие shebang в первой строке файла шаг 2 - указывает ли shebang на настоящий двоичный файл? (пытаться which [path after shebang]) шаг 3 - если шаг 2 подтверждается, ./test.sh должен работать, иначе .. шаг 4 - попробуйте /full/path/to/sh test.sh
то, что вы опубликовали, Чарли, не имеет никакого смысла
вам нужно изменить разрешения:
chmod +x test.sh