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

[Chet Ramey]

On 3/1/17 7:43 AM, Stephane Chazelas wrote:
> 2017-02-28 16:18:05 -0500, Chet Ramey:
> [...]
>>> Just my personal opinion, but I think I'd rather the spec had
>>> been updated to accomodate the bash (and many other shells)
>>> behaviour rather than bash breaking its backward compatibility
>>> to comply to a requirement that is not particularly useful
>>> myself.
>>
>> That's why I made the bash-4.3 behavior available via the shell
>> compatibility level mechanism.
> [...]
> 
> That's good to have at least a mechanism to make sure scripts
> are not going to be broken by a future, incompatible version of
> the shell.
> 
> Would you recommend people start adding:
> 
> shopt -s compat44 2> /dev/null || true
> 
> at the start of their script that they develop for bash-4.4 now
> so that it still works even when bash-6.0 makes a non-backward
> compatible change?

I know this isn't a serious question, but I'll answer it anyway.
No. People should look at the effects of each compatibiity version
option and decide for themselves.

> 
> It seems there's a compatXX option for each of the versions
> since bash31. Will you keep doing it for every version?

Most likely, but I will probably phase out the shopt options in
favor of BASH_COMPAT.

> Maybe a shopt -s compat=44 to avoid filling up the option
> namespace would be better.

This doesn't make any sense, since shopt doesn't work that way.
Plus there's already BASH_COMPAT.

> It's not clear what combining several
> compat options could do. For instance with shopt -s compat31
> compat43 would not be compatible with bash-4.3 in that the [[ =~
> ]] operator would work the bash-3.1 way. That could cause
> confusion.

Compatibiity options are all mutually exclusive, last one wins.

-- 
``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/