On 3/1/17 12:06 PM, Greg Wooledge wrote:
> The purpose of the compat options is that you, as the script writer,
> right now, can write and test and deploy your script on a specific
> version of bash. Once you know that your script works on this version
> of bash (say, 4.4) you can set the compat option to say "Dear future
> version of bash, please treat this script the same way bash 4.4 did."
> Now you know that your script will continue to work even if bash 5.3
> changes some crazy thing according to a POSIX-2023 ruling that you can't
> possibly predict today.
This is true, in the sense that the way the compatibiity options are
implemented: if you set BASH_COMPAT=31 you get bash-3.1 behavior for
everything that is controlled by the shell compatibility level. That's
because all of the tests are written like
if (shell_compatibility_level > 43)
stuff
But everything else is as the current version implements it.
Backwards compatibility is tricky. In general, you try to break it in
only a few cases: genuine bug fixes, changing requirements (Posix is
one such requirement), or to add desired functionality that can't be
done any other way. Only a subset of those are controlled by a
compatibility option. Setting BASH_COMPAT=42 is not intended to make
bash behave like bash-4.2 in all cases.
If you run up against a change in backwards compatibility that is
controlled by the compatibility version, you can use it. But it's
mostly intended as a stopgap so people can change their scripts if
they can.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
