Напишите свои скрипты в соответствии с POSIX, а затем протестируйте их с помощью совершенно другой оболочки, например dash
, zsh
, пдкш
или что у вас. Избегайте темных углов и серых участков на языке скорлупы; делать все "канонически".
Конечно, это не доказывает, что ваш код не обнаруживает какую-либо ошибку Bash в старой версии, но это повышает надежность. Во-первых, ошибки Bash чаще встречаются в конструкциях, специфичных для Bash (которые не используются переносимыми скриптами), а также в темных углах и серых областях (которые не используются во многих скриптах).
Другими словами, не стоит быть первым в мире скриптером оболочки, который использует четырехкратный обратный eval.
Одним из преимуществ переносимости сценария является то, что, предположим, пользователь обнаружит, что ваш сценарий не работает в его установке, в которой установлена более старая версия Bash.Что ж, поскольку сценарий не является специфичным для Bash, возможно, они смогут заставить его работать с альтернативной оболочкой, которая у них уже установлена.
Есть только два способа узнать, обнаружил ли ваш код какую-либо историческую ошибку, специфичную для Bash. Только один из этих способов наполовину надежен (тот, который вы не хотите делать: вытащите старые версии Bash и протестируйте). Другой способ - изучить историю изменений Bash и попытаться определить, могут ли ошибки, существовавшие в каких-либо старых версиях, которые вас интересуют, влиять на то, что делает ваш скрипт.
Я бы просто оставил виртуальную машину, на которой размещен какой-нибудь старый дистрибутив, и время от времени проводил бы регрессионный тест.