Забавная история о изменении поведения %ENV, обнаруженное на старом легаси.
опубликован: 2015-04-01 15:15
последняя редакция: 2024-07-13 14:08

У вас неправильный хеш, и он даёт неправильный val

Занимаясь на новой работе перелопачиванием большого количества legacy code, на одной из тестовых машинок обнаружил неработоспособность нужного скрипта. Суть была в том, что в main-модуле формировалась переменная окружения $ENV{bla-bla-bla}, а в какой-то внутренней библиотеке она использовалась. Но не просто так: в главной программе в эту переменную запихивался объект, а в библиотеке, соответственно, к этому объекту применялся некий метод. Казалось бы, хеш - он и есть хеш, можно передать в нем все, что хочется (несмотря на то, что я лично с трудом представляю, как мы в переменную окружения юникса запихиваем какой-нибудь объект: идеологически безумно, в консоле неработоспособно, но в принципе, в перловой программе работать должно). Оно и работало на всех компах, кроме одного. Причем, на этом компе в переменной окружения, в конечном итоге, оказывался не объект, а его название с адресом (в виде строки). Бред полный.
Проведенное исследование показало, что тестовые машины отличаются версией перла: 5.10, 5.14 и 5.18
Интеллектуальный поход на perl.org, привел к нахождению новой для 5.18 фичи: Defined values stored in environment are forced to byte strings
Другими словами, как бы не извращались, что бы ни делали - в элементах значений хеша %ENV будут только принудительные строки. С одной стороны это кажется правильным, но с другой %ENV - это уже не хеш, а какой-то новый тип данных.