On 6/14/17 5:52 PM, L A Walsh wrote:
> Chet Ramey wrote:
>> But people don't work in Unicode. They work in their own locale.
> ----
> Ok, I have my locale set to latin9 (iso8859-15).
>
> Attached is a pic of how files display in a console
> and how they display in vim.
I am less concerned with how glyphs display in a console than how they
are interpreted as alphanumerics given the C library interfaces that
determine those character classes.
Users expect alphanumerics in their own locale to be allowable as
alphanumerics, and characters that are not to not be allowable as
alphanumerics, and they expect that to be consistent across programs
running on the same system using the same locale. That's the basis to use
for determining whether or not a character is a valid part of a shell
identifier.
A character that is classified as an alphanumeric in a particular locale,
but not in another, can lead to portability problems. That's what we're
debating here, not how something gets displayed in a text editor.
>
>> That locale may be consistent with Unicode, and it may not. Adding
>> something that doesn't respect a user's locale isn't useful.
>>
> What do you mean by respect? I am running in the locale and
> characters from other locales still display correctly.
See above.
> Isn't that respecting both the local locale as well as
> the one being displayed?
How glyphs are displayed is not an issue for the shell to be concerned
with.
> How is having UTF-8 for files and text not showing
> respect?
Look at the the issue with different locales classifying
characters as alphanumerics differently, and how that would impact
variable names incorporating locale-specific characters in `portable'
scripts.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
