Доброе утро! Все выходные разгребал бухгалтерию, да готовил рекламную кампанию на завтра. Даже баг мимолётом поправил у клиента. После подключения ddos-guard, мониторинг сильно засопливил. Ну тут очевидно, docker контейнеры с экспортерами снимают показатели по домену, а домен-то теперь за ddos-guard, пришлось прокинуть hosts файл и ходить напрямую за метриками.
Ладно. Сегодня на повестке дня: Зачем добавлять ./ перед исполняемым файлом или скриптом.
Когда я только начал изучение linux, я столкнулся с проблемой, что не могу выполнить bash скрипт. Вроде и атрибут +x указан, но после запуска получалидинахуй:
Интернета тогда не было, максимум на что я мог рассчитывать это Фидонет. Но он мне не понадобился, методом тыка я самостоятельно смог решить задачу с запуском. Наверное знания MSDOS как-то натолкнули поставить перед скриптом символы
Но почему так? Это же не логично! Нет, всё логично. Это сделано для безопасности и от кривых рук. Например:
Работаешь ты под рутом, заходишь в домашнюю папку какого-нибудь пользователя, делаешь ls и хуяк, нет у тебя больше сервера. А что произошло?
А произошло то, что в папке пользователя лежал бинарник под названием ls. Который содержал руткит, он то и выполнился. Хотя ты ожидал что выполнится нативная утилита ls.
Вот поэтому если запускать какую-то дичь или скрипт БЕЗ
А вот когда указываешь
Аналогично можно запускать указывая полный путь к программе/скрипту:
Здесь так же PATH будет игнорироваться. Но вопрос остается: Как это может быть мерой безопасности, если эта мера обходится банальным
Нууу… это больше для предотвращения несчастных случаев. Указав явно
Как вариант, можешь добавить точку в PATH и тогда можешь запускать скрипты без
Добавляем текущий каталог в PATH. Теперь
Так, теперь про cron. Если хочешь чтобы твои скрипты гарантировано запускались в cron, всегда указывай полные пути до программ/утилит. Так как cron может смотреть в какой-то свой PATH или вообще через sh запускаться. Встречал/встречаю я такие случаи. Поэтому рекомендуется писать скрипты в таком духе:
Определяем полный путь до утилиты cat, а потом уже используем как переменные. Даже если cat не найдется через PATH, скрипт в кроне будет выполнен, так как указаны полные пути. Заметки про PATH можешь глянуть в этом посте.
Вот так. Хорошей тебе рабочей недели. Вечерком после интеграции закину еще чтива. На связи!
tags: #bash #linux
—
💩 @bashdays
Ладно. Сегодня на повестке дня: Зачем добавлять ./ перед исполняемым файлом или скриптом.
Когда я только начал изучение linux, я столкнулся с проблемой, что не могу выполнить bash скрипт. Вроде и атрибут +x указан, но после запуска получал
script.sh: command not found
Интернета тогда не было, максимум на что я мог рассчитывать это Фидонет. Но он мне не понадобился, методом тыка я самостоятельно смог решить задачу с запуском. Наверное знания MSDOS как-то натолкнули поставить перед скриптом символы
./Но почему так? Это же не логично! Нет, всё логично. Это сделано для безопасности и от кривых рук. Например:
Работаешь ты под рутом, заходишь в домашнюю папку какого-нибудь пользователя, делаешь ls и хуяк, нет у тебя больше сервера. А что произошло?
А произошло то, что в папке пользователя лежал бинарник под названием ls. Который содержал руткит, он то и выполнился. Хотя ты ожидал что выполнится нативная утилита ls.
Вот поэтому если запускать какую-то дичь или скрипт БЕЗ
./ то оболочка будет искать эту дичь/скрипт в указанных каталогах. Которые определены в 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 выполнится, без указания этого хитрого ./ Но так делать не рекомендуется, наступишь на грабли или даже на граблища!Так, теперь про cron. Если хочешь чтобы твои скрипты гарантировано запускались в cron, всегда указывай полные пути до программ/утилит. Так как cron может смотреть в какой-то свой PATH или вообще через sh запускаться. Встречал/встречаю я такие случаи. Поэтому рекомендуется писать скрипты в таком духе:
CAT=$(which cat)
$CAT script.sh
Определяем полный путь до утилиты cat, а потом уже используем как переменные. Даже если cat не найдется через PATH, скрипт в кроне будет выполнен, так как указаны полные пути. Заметки про PATH можешь глянуть в этом посте.
Вот так. Хорошей тебе рабочей недели. Вечерком после интеграции закину еще чтива. На связи!
tags: #bash #linux
—