Excellent! I can stop trying to dig in to the code and understand where all the word expansions happen.
So strange to find those one off bugs, and great that it was only one. Do you have, or working on a patch that can be applied to a build? Thanks Jeff On Thu, Jan 9, 2025 at 1:20 PM Chet Ramey <chet.ra...@case.edu> wrote: > On 1/8/25 1:25 PM, Jeff Ketchum wrote: > > I ran into a strange bug using newer versions of bash, I haven't isolated > > it to a specific release. > > > > OS1: Oracle Enterprise linux 9,4 bash 5.1.8(1) > > OS2: Gentoo linux bash version 5.2.37 > > older bash: > > OS3: centos linux 7.9 bash 4.2.46(2) > > > > In using unicode group separator character U 241D, > > https://www.compart.com/en/unicode/U+241D, 0x241D > > I set the IFS to this unicode, and have U+241E and U+241F characters in > the > > data. > > When assigning to an array, and using for var in "${array[@]}"... > > it ends up splitting the data at unexpected locations. > > Thanks for the report. This turned out to be an easy fix: there was one > place (one!) where word expansion didn't take into account that multibyte > characters can be protected by bash's internal quoting. > > Chet > -- > ``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/ >
