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