Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #15752 > unrolled thread

Re: Unicode range and enumeration support.

Started byEli Schwartz <eschwartz@archlinux.org>
First post2019-12-18 15:28 -0500
Last post2019-12-18 15:28 -0500
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Unicode range and enumeration support. Eli Schwartz <eschwartz@archlinux.org> - 2019-12-18 15:28 -0500

#15752 — Re: Unicode range and enumeration support.

FromEli Schwartz <eschwartz@archlinux.org>
Date2019-12-18 15:28 -0500
SubjectRe: Unicode range and enumeration support.
Message-ID<mailman.1103.1576700919.1979.bug-bash@gnu.org>

[Multipart message — attachments visible in raw view] — view raw

On 12/18/19 3:13 PM, Greg Wooledge wrote:
> On Wed, Dec 18, 2019 at 03:08:20PM -0500, Eli Schwartz wrote:
>> So all bash needs to do to print {Z..a} is to take Z == ASCII decimal 90
>> and a == ASCII decimal 97, then enumerate the numbers 90-97 and
>> translate them into ascii. No locale awareness is needed, no heuristics,
>> no invocation of the locale subsystem, you don't even need to hardcode
>> the ASCII range in source code.
> 
> Until you want to use bash on an EBCDIC system. ;-)

Oof, that was mean. :p (Also, why does this still exist.)

(But I guess we all realize that this just means bash needs to rely on
the existing support for translating the ASCII locale, and still doesn't
need to enumerate a lookup code of characters for this especial purpose.)

>> And that's why bash can support enumerating a range of ASCII characters
>> in LC_COLLATE=C order, when it cannot (easily) do so using other locales.
> 
> Yup.
> 


-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web