On 11/4/22 12:22 PM, Alex fxmbsw7 Ratchev wrote:
what on yours i ask , o i see now , 4.2 ..
i quote right in ${ // - to me , preserved quotes are • an invalid youth
bug to be replaced with better by bash.c changes
which it seemfully did
The question is, as always, tradeoffs. Do you fix bugs or not? Do you make
the behavior more consistent across operations, even if incompatibilities
(as above) result? Do you tighten up behavior where previous versions were
too permissive, even if people will have to change their code as a result,
or not? Do you introduce new features, or not? Do you make things opt-in,
or opt-out? The answers are not always the same.
Greg, for example, puts a lot of value in being able to use the same code
from bash-4.2, which was released in 2010, through the current version.
That's the tradeoff he's willing to make when answering these questions.
This was the entire rationale for the compatibility mode in the first
place: if you want things as they were before, set the appropriate
compatibility variable. The same is true of features controlled by shell
options.
Backwards compatibility is important, and I put a lot of effort into it.
But I nudge things forward when I think it's warranted. As you've seen,
there's always spirited disagreement.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
