Re: [PATCH] multibyte_identifiers: opt-in UTF-8 variable names (UAX #31 + NFC) behind a root-controlled system switch

Le 24/08/2026 à 21:14, Sebastian Peters via Bug reports for the GNU 
Bourne Again SHell écrivait :

> sounds like a good idea; it could also be useful in the field of education. For
> me, the question is rather: Why should Bash continue to be limited to ASCII when
> all other programming languages and shells have long been able to do this? So

Broad statements such as this can't be used as engineering decisions for
such a change with already identified and disruptive side-effects on a
language which has been created and was born from the get-go to sequence
system administration, maintenance and life-cycle operations.

> far, I haven’t been able to find a truly technically sound answer here as to why
> this shouldn’t be possible.

You won't find such a technically sound answer as to why this shouldn't 
be possible because it is perfectly technically possible to implement 
UTF-8 identifiers. It is not about a technical limitation.

What the blocking reasons and the source of opposition are is not about 
technicality. Putting aside the identified side-effects with homographs, 
the region's specific input methods limitation and the profound grammar 
and parser changes it implies, it is the lack of engineering grounds for 
such a change that has no sense in a narrow-purpose language (as opposed 
to all-purposes language) that is Bash or the 'nix shell in general.

> Admittedly, the added value may be minimal,

Indeed, that's part of the core problems with this proposal.

> but if the added value were that minimal, ZSH, Bash (Windows

If Bash for Windows has such a feature, that is Bash for Windows with
different baseline goals than 'nix's Bash.

As for Zsh, they diverged from POSIX constraints from the start and
followed different design goals than Bash. A feature that fits one
project's design goals is not automatically evidence that it should
fit another's. Zsh having it is a precedent, not a justification.

> But thank you for not immediately nipping the topic in the bud—most of you here
> have shown that you have the maturity to discuss even difficult topics.

It is the kind of topic that attracts defensive positions such as my 
own, and it also attracts a lot of proselytism.

You cannot balance emotionally charged discourses with technicality. As 
an engineer I cannot choose for a change based only on some coolness or 
popularity factor.

As for "it would be an optional feature", that does not make it free.
It still has to be designed, implemented, and maintained across the
parser and every downstream tool that reads Bash scripts. That cost
does not answer the original question: what does Bash gain from
carrying it at all.

I can see the benefit of the added freedom that comes from expanding the 
charset for identifiers, but I cannot ignore the engineering constraint 
I have learned to live with over the years working internationally with 
teams spread across different regions and alphabets: the more 
appropriate choice, for cross-team code review, tooling, and debugging, 
turns out to be having everyone use ASD-STE100, regardless of individual 
region, locale, language, and alphabet.

-- 
Léa Gris

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments