On Fri, Nov 24, 2023, 17:32 Chet Ramey <chet.ra...@case.edu> wrote:
> Thanks for the report. Nice attention to detail. This test has not changed
> substantially since it was donated in 2012. Namerefs didn't exist then, and
> my guess is that John Kearney wasn't familiar or comfortable with ${!x[@]}.
>
> https://lists.gnu.org/archive/html/bug-bash/2012-02/msg00063.html
>
> > If that's fixed, the zh_TW.BIG5 tests run but fail. I'm not sure what
> > the original intent was, they seem to expect U+00F6..U+00FE to be
> > encoded as 0xF6..0xFE which is not the case.
>
> You'd have to ask John, I guess. These tests never got run in any
> case, since the original code, as you pointed out, assumed the array
> wasn't sparse, and the discrepancy never got discovered. My guess is
> the point is to check how codepoints that don't encode valid characters
> in the target character set (though 0xf7 is valid) are displayed, but
> you can't be sure. In any case, they're just wrong.
>
> This was part of a much wider discussion about unicode character conversion
> in bash-4.2, which you might find interesting as a twelve-year-old
> discussion.
>
Thanks for all the info. I only noticed the problem when trying to figure
out the Big5 macOS 14 test failure that I posted about earlier today.
>
