Доброе утро! Все выходные разгребал бухгалтерию, да готовил рекламную кампанию на завтра. Даже баг мимолётом поправил у клиента. После подключения ddos-guard, мониторинг сильно засопливил. Ну тут очевидно, docker контейнеры с экспортерами снимают показатели по домену, а домен-то теперь за ddos-guard, пришлось прокинуть hosts файл и ходить напрямую за метриками.

Ладно. Сегодня на повестке дня: Зачем добавлять ./ перед исполняемым файлом или скриптом.

Когда я только начал изучение linux, я столкнулся с проблемой, что не могу выполнить bash скрипт. Вроде и атрибут +x указан, но после запуска получал идинахуй:

script.sh: command not found

Интернета тогда не было, максимум на что я мог рассчитывать это Фидонет. Но он мне не понадобился, методом тыка я самостоятельно смог решить задачу с запуском. Наверное знания MSDOS как-то натолкнули поставить перед скриптом символы ./

Но почему так? Это же не логично! Нет, всё логично. Это сделано для безопасности и от кривых рук. Например:

Работаешь ты под рутом, заходишь в домашнюю папку какого-нибудь пользователя, делаешь ls и хуяк, нет у тебя больше сервера. А что произошло?

А произошло то, что в папке пользователя лежал бинарник под названием ls. Который содержал руткит, он то и выполнился. Хотя ты ожидал что выполнится нативная утилита ls.

Роман Шубин
Роман Шубин
CEO & CTO, Главред в «Цифровой улей»
Задать вопрос
Вот поэтому если запускать какую-то дичь или скрипт БЕЗ ./ то оболочка будет искать эту дичь/скрипт в указанных каталогах. Которые определены в PATH. Соответственно если домашний каталог пользователя не определен в PATH, то и возникает ошибка command not found.

А вот когда указываешь ./script.sh ты говоришь оболочке - Эй бля! Игнорируй PATH и запускай мне эту пепяку! Да, вот прям отсюда!

Аналогично можно запускать указывая полный путь к программе/скрипту:

cd ~
./script.sh

# или

/home/user/script.sh

Здесь так же PATH будет игнорироваться. Но вопрос остается: Как это может быть мерой безопасности, если эта мера обходится банальным ./ ?

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

Как вариант, можешь добавить точку в PATH и тогда можешь запускать скрипты без ./ например:

export PATH=$PATH:.
script.sh

Добавляем текущий каталог в PATH. Теперь script.sh выполнится, без указания этого хитрого ./ Но так делать не рекомендуется, наступишь на грабли или даже на граблища!

Роман Шубин
Роман Шубин
CEO & CTO, Главред в «Цифровой улей»
Задать вопрос
Так, теперь про cron. Если хочешь чтобы твои скрипты гарантировано запускались в cron, всегда указывай полные пути до программ/утилит. Так как cron может смотреть в какой-то свой PATH или вообще через sh запускаться. Встречал/встречаю я такие случаи. Поэтому рекомендуется писать скрипты в таком духе:
CAT=$(which cat)
$CAT script.sh

Определяем полный путь до утилиты cat, а потом уже используем как переменные. Даже если cat не найдется через PATH, скрипт в кроне будет выполнен, так как указаны полные пути. Заметки про PATH можешь глянуть в этом посте.

Вот так. Хорошей тебе рабочей недели. Вечерком после интеграции закину еще чтива. На связи!