И не дай бог кто-то решит ее перезаписать, получит в лоб ошибкой:
bash: VAR: readonly variable
Буквально сегодня ебался со скриптом уволившегося коллеги и не мог понять, какого лешего я получаю неочевидные результаты.
Оказалось, всё очень даже очевидно. Этот скуфяра мало того что применил ООП в скриптах (это пиздец), так еще и воспользовался «readonly». Спасибо тебе дорогой друг. Надеюсь на новом месте, тебе такого с кубернейтсами не позволяют делать. Диверсант блядь.
Еще раз, НЕ НУЖНО УСЛОЖНЯТЬ, ООП и выкрутасы оставь для программистов.
Ладно. Теперь про «readonly». Если не можем победить, значит нужно изучить и победить. Это как в анекдоте 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 от вмешательств и ни одна собака его не зареврайтит. И порой даже ты сам.
В общем изучай. Хороших тебе предстоящих выходных и береги себя!
tags: #bash #linux
—
@BASHDAYS