Re: Patch for unicode in varnames...

[George]

On Tue, 2017-06-06 at 10:20 -0400, Greg Wooledge wrote:
> (OK, in reality, I am not taking any of this seriously.  This entire
> proposal and discussion are like some bizarre fantasy land to me.  Bash
> is a SHELL, for god's sake.  Not a serious programming language.  Even
> serious programming languages are not ready for this; see the Python
> proposal that was mentioned up-thread.)
> 
I don't think "shell" and "serious programming language" must be considered 
mutually exclusive.
Shell scripting is "serious" in the sense that there are people who rely upon 
and actively develop shell scripts to keep their products working. If
the language itself seems not "serious" I think that is because not enough 
effort has been made to extend and improve its functionality over time. (At
least, not in the Bash project...  Korn Shell has done some good work along 
those lines.)
But I think the "interactive" aspect is probably the most compelling argument 
for supporting something like this. The shell can serve as one of the
primary tools for operating the computer. As such it should also aim to be a 
comfortable environment. If you tell a programmer that a shell only
accepts ASCII in some contexts, there's a fair chance they'll understand why, 
and accept the limitation. For more casual users, this may not be the
case. I think they'd be likely to wonder why they can't use accented 
characters, or other alphabets for parameter names. I don't think there's a
particularly good reason not to allow it...  Though I'd personally like to see 
it implemented in a way that allows scripts to take advantage of that,
and still work reliably regardless of the locale setting in which they're 
ultimately run.
As a side note, I had expressed concern that Bash might not work correctly with 
GB-18030 encoding, but it appears that I was wrong. I set up a
terminal to display the GB-18030 character set, set the locale within the 
terminal to GB-18030, and formed a string that I would expect to expose a
parser bug (a string of multi-byte Chinese characters including 0x7C, the byte 
that corresponds to the ASCII vertical bar character), but it appeared
to parse the string correctly according to the locale rather than break it up 
on the 0x7C byte. So that's good. :)