Re: break no longer breaks out of loops defined in an outer context

[Chet Ramey]

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    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/