On 2026-05-20 at 16:10 +0000, Ótzï fón GlüϷgor wrote: > I understand that this raises questions around portability, parsing, > locale handling, and Unicode confusables. That is why I think it > should be an explicit Bash-specific opt-in feature, not a default > behavior change. > Would such a feature be considered acceptable for Bash if implemented > carefully and accompanied by tests?
Hello Ótzï I don't think this would be a good idea. An innocent line like echo "This item will cost you $price€" would suddenly change its behavior (variable «price» or variable «price€») depending on your option. The command line π=3.14159 calc could be running two different programs. This proposal would create a booby trap. And bash already has enough pitfalls. The definition of an identifier is a very deeply nested one in a language. Were we designing a new language, then the proposal would be ok. Here, we have 50 years of shell scripts that work under different ruls that would (potentially) act differently. Not just a syntax error that is now accepted. A program that did something and this flag would make it do something else. Also, while some some other languages allow per-file switches changing their behavior (some perl's use, python's from __future__ ...), that's not the case in bash. An option in a sourced file would easily leak into the main script. And conversely, "library" scripts and helpers would need to be coded defensively against the potential usage of such option in the parent script. Thus, I don't think this option would be a suitable addition. Not as a shopt, or even as a compile-time configure option. I think such program should be named something other than bash. Sorry. On a technical note, I suspect the changes to the parser you would require for this would be non-trivial. Your feature would probably be complex to add. My 2¢ Ángel
