Should bash be expected to change in ways that break non-trivial amounts of existing scripts at some point in the (near/<5y) future? How much change has it gone trough in the last ten years compared to, say, python or perl?
closed as not constructive by Blrfl, gnat, Mark Booth, GlenH7, ChrisF♦ Mar 7 at 21:56
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.
Bash isn't going anywhere, because if it did break existing scripts, it would cause huge problems. To the contrary, Bash has gone out of its way to preserve backwards compatibility with every new syntax addition.
The syntax of bash is unlikely to change significantly. Changes to it could have catastrophic effects across unix systems (startup scripts not working after the upgrade).
If you are upgrading a system and see that bash is upgrading, it may be necessary to test those ancient scripts to make sure everything is still running correctly. It probably will, but I wouldn't want to be the one doing a "OMG Fix everything yesterday!" when something is doesn't work right after trusting that everything will.
In theory, if people followed best practices for the bash scripts, it should work, but then again, please don't take my word for it.
Perl and Python keep backwards compatibility within major version numbers. Something written for perl 5.001 (1995) still runs correctly in perl 5.16.1 (August 9, 2012). A script for perl 5 will need to run in compatibility mode with perl 6.
Python appears to follow a similar "nothing breaking within a major version". Also give Python 2 or 3 a look for python backwards compatibility between major versions.