Hi Léa,
I agree with one important part of your response: the fact that UTF-8 identifiers are technically implementable does not, by itself, establish that Bash should implement them. The relevant question is whether the feature has enough value to justify its implementation and maintenance cost. I do not think, however, that the current discussion establishes that the engineering case is absent. One distinction seems important here. POSIX does not standardize non-ASCII shell identifiers. Its portable shell naming rules are intentionally restrictive. POSIX leaves room for implementations to accept additional environment-variable names beyond the portable name space as an extension, but that is implementation-defined behavior; it should not be confused with a POSIX specification for Unicode shell identifiers. Likewise, I would not characterize the current Bash situation simply as “Bash has ASCII identifiers”. Bash's name syntax is currently specified in terms of letters, digits and _, but it does not define a Unicode identifier model based on properties such as XID_Start and XID_Continue. In single-byte locales, some non-ASCII characters may be accepted depending on the locale's classification functions, but this is neither consistent nor part of a documented Unicode identifier profile. The proposed change is therefore not merely “replacing an ASCII character class with a Unicode character class”. It would introduce an explicit and standardized Unicode identifier model where Bash currently has no such specification. That distinction matters to the engineering argument. The proposal is not to make the existing POSIX shell identifier rules meaningless. It is to provide an additional, explicitly defined identifier profile for Bash, based on UAX #31 and NFC. POSIX compatibility can remain a separate concern. A shell can still have a deliberately conservative portable subset while allowing its native language to be more expressive. I also think the argument from Bash's purpose deserves some qualification. Bash is certainly a shell for system administration, automation, maintenance and lifecycle operations. But that describes what the language is used for; it does not by itself establish what its internal identifier syntax must look like. There is a difference between external interfaces and names that exist only inside the shell language. POSIX portability constraints are particularly important at the interfaces where shell scripts communicate with the Unix environment. A shell-internal variable name is a different layer. For example, permitting a script to contain a variable named $aéroport does not require Bash to change the syntax of standard environment variables, utility names, command-line interfaces, or any other POSIX-defined external interface. The relevant design question is therefore not “does system administration require Unicode?” It is “does Bash have a good engineering reason to keep its internal identifier model permanently more restrictive than the Unicode-aware text environment in which it operates?” I also think that “the added value is minimal” needs to be treated as a claim that can be examined rather than as a premise. There are at least three concrete sources of value. First, there is international use. For some users, the difference between an ASCII-only language and a language whose identifiers can naturally represent their own language is not merely cosmetic. This includes education, examples written for local audiences, and code bases where domain concepts have established names in a non-Latin script. Second, there is consistency. Bash already operates in an environment where Unicode text is unavoidable. Introducing a defined identifier profile does not make Unicode suddenly appear in Bash; it gives a precise language-level meaning to something which is currently not defined in Unicode terms. Third, there is predictability. UAX #31 provides a common basis for identifiers through XID_Start and XID_Continue, and it is specifically designed so that languages can define their own profiles. With NFC and an explicitly documented Bash profile, the rule becomes something tools and implementations can target consistently. That is potentially an engineering improvement over leaving identifier semantics tied to Bash's existing character-model assumptions. This is also why I would not treat the security question as an argument against Unicode identifiers as such. Homographs and confusables are real problems. They should be part of the design discussion. But the existence of a security problem does not establish that the right engineering response is to prohibit the entire feature. A more precise approach is possible: Unicode identifiers -> UAX #31 profile -> NFC -> additional Bash restrictions if necessary -> possible tooling/linting policies for confusables In other words, the language can define what constitutes a valid identifier without pretending that every visually distinguishable identifier is equally safe in every context. The same applies to project policy. An organization can reasonably decide: “All identifiers in this repository must be ASCII.” That is a perfectly coherent engineering convention for cross-team review and debugging. But it is a different question from: “Should the language itself make non-ASCII identifiers impossible?” A language feature does not force projects to use it. A language restriction does remove the option from projects that have a legitimate reason to use it. This is why I do not find the ASD-STE100 argument conclusive. I can fully accept the practical value of a common restricted language for international documentation and team communication. But a coding convention and a language capability solve different problems. On the implementation side, I also agree that “optional” does not mean “free”. The parser, tests, diagnostics and downstream tooling all have to be considered. But I think we should distinguish implementation cost from the claim that this would require “profound grammar and parser changes”. The proposed feature is narrowly scoped: an identifier grammar based on well-defined Unicode properties, rather than arbitrary Unicode syntax throughout the shell language. The exact impact should therefore be established component by component. For example: variable and parameter parsing assignment declare and related builtins function names, if included completion and Readline interaction diagnostics and debugging output syntax highlighting and other downstream tooling Those are real engineering tasks. But “this touches several components” is not the same proposition as “this is fundamentally incompatible with Bash's design”. I think the latter would need to be demonstrated rather than assumed. Another option I could see, especially to address the issue of homoglyphs more reliably, would be to allow only certain selected Unicode blocks. For example, only the Latin Unicode blocks. Could the current patch file already serve as a basis for reducing the implementation effort? Regards Sebastian
