On Thu, Aug 6, 2026 at 2:16 PM Chet Ramey <[email protected]> wrote: > > On 8/4/26 11:35 PM, zheng wrote: > > # Bash bug report: variable-name parsing swallows first byte of multibyte > > UTF-8 char > > > > ## Summary > > In a UTF-8 locale, `$VAR` immediately followed by a multibyte (non-ASCII) > > character causes bash to treat the first byte of that character as part of > > the > > variable name. > > Thanks for the report. > > Well, certain characters on certain systems. Certainly that particular byte > on macOS. > > Bash knows that variable names are composed of bytes, and that only certain > bytes are valid ([_0-9a-zA-Z]). It uses isalnum(3) and isalpha(3) to check, > trusting that in, say, en_US, characters > 127 and <= UCHAR_MAX will fail > both tests. > > This isn't strictly kosher, because bash uses setlocale(3) to set the > various locale categories at program startup, so these checks are subject > to LC_CTYPE. In this case, the first byte of the `，' multibyte sequence > returns true for isalnum() (specifically islower()), even though the > numeric value of the byte is 239, and it certainly doesn't render as > anything in Terminal (though isprint() returns 1). > > (I seem to remember something about macOS incorrectly returning true for > isalpha/isupper/islower/isalnum for characters in this range, but I can't > remember exactly what. Nevertheless.)
This came up for isspace relatively recently: https://lists.gnu.org/archive/html/bug-bash/2023-05/msg00132.html
