On 04/06/2560 01:00, George wrote: > There's a series of trade-offs between keeping the implementation relatively > simple vs. supporting equivalency where the user may reasonably expect > it. I will personally never use non-ascii in a bash script, even though I use unicode extensively, also in the shell.
But the fact that unicode functions are already supported does seem to pave the way for allowing variable names in unicode. For consistency, it should really be the same handling as function names -- I am expecting no equivalency support in the current function name implementation, and I am also guessing that many types of non-ascii space are also allowed in function names already. Which does makes sense: if people want to shoot themselves in the foot by using similar/same looking but actually different glyphs and spaces, it would be too tiresome to try to prevent that. Peter
