Охохо, привет! Размазывать бытовуху не буду, сразу к делу. В Bash есть офигительная команда, называется она readonly. С помощью неё ты сможешь защитить любую переменную от изменения. Получается этакая константа, которую довольно сложно перезаписать.
И не дай бог кто-то решит её перезаписать, получит в лоб ошибкой:
bash: VAR: readonly variable
Буквально сегодня ебался со скриптом уволившегося коллеги и не мог понять, какого лешего я получаю неочевидные результаты.
Оказалось, всё очень даже очевидно. Этот скуфяра мало того, что применил ООП в скриптах (это пиздец), так ещё и воспользовался readonly. Спасибо тебе, дорогой друг. Надеюсь, на новом месте тебе такого с кубернейтсами не позволяют делать. Диверсант, блядь.
Ладно. Теперь про readonly. Если не можем победить, значит, нужно изучить и победить. Это как в анекдоте 18+:
Анекдот 18+
Поехали двигать!
Переменная защищается так:
readonly VAR=1234
Если её попытаться переопределить, то моментально отправляешься в пешее эротическое. Возникает логичный вопрос — как её откатить обратно и сделать нормальной переменной?
В голову приходит логичный ответ, сделай так:
unset VAR
А вот и нет! Сразу получишь хуем ошибкой по башке: bash: unset: VAR: cannot unset: readonly variable.
Хм… интересное кино. А чё делать? Не использовать readonly! Ну а если пришлось с этим столкнуться, придётся использовать древнюю магию. Мы её, кстати, недавно использовали в этом посте.
Чтобы заансетить константу, открываем «Ящик Пандоры»:
gdb -ex 'call (int) unbind_variable("VAR")' --pid=$$ --batch
Если получил $1 = 0, значит, всё прошло успешно.
.bashrc и т. п.Если кто-то захочет что-то переопределить, у него ничего не получится. Защита от дурака. Но помни, что древняя магия GDB может не сработать на этом проклятии, если ты не root.
Например, можно защитить переменную PATH от вмешательств, и ни одна собака её не зареврайтит. И порой даже ты сам.
В общем, изучай. Хороших тебе предстоящих выходных и береги себя!
Комментарии