From: Stan Marsh
Subject: Re: [PATCH] multibyte_identifiers: opt-in UTF-8 variable names (UAX 
#31 + NFC) behind a root-controlled system switch
Date: Mon, 27 Jul 2026 08:38:06 -0600
>I think the phrase "beating a dead horse" applies here.
>Aren't you going to awfully extreme lengths to try to rescue an idea that
>pretty much everyone else has concluded (correctly) is just inherently a bad
>idea?

I can't agree with that; that might only apply to people who have been working 
exclusively in this ecosystem from the start.
Today I started migrating internal company scripts from a macOS/Windows 
environment to Ubuntu. I thought migrating from macOS to Ubuntu would be a 
breeze, but I immediately got an error saying that a variable name 
(Σ=“<value>”) was rejected. At first, it seemed like a bad joke to me, until I 
found out that this is actually how it works in Bash. While code coming from 
the Windows ecosystem requires significantly more adaptation, there are no 
issues with the identifiers there. That’s why I’ve now decided to run ZSH as 
the shell on Ubuntu (since the client insists on Ubuntu), so that at least the 
identifiers—which are very important in the program structure—will survive the 
migration. We’re talking about approximately 1,500 identifiers, the majority of 
which are not ASCII-compliant, and many of which are subject to strict 
corporate policies and are used by a large number of people. Therefore, they 
cannot simply be made ASCII-compliant.

Since a patch like this solves this problem and saves a lot of headaches when 
migrating to Linux systems, I consider it very important and long overdue. ZSH 
has been able to do this since, I believe, 2004; Windows has been able to do it 
since NT (2001); and macOS has been able to do it since 2019 as well (also 
requiring a UTF-8 locale).

A shell that aims to ensure “portability” should allow more characters rather 
than fewer, or at least not reject them outright as errors (perhaps just issue 
a warning?). This would also ensure portability to other major shells. Perhaps 
this discussion could take a cue from macOS or ZSH and how they’ve managed to 
achieve this.

Best regards,Ruben

Reply via email to