Eric Blake wrote:
They still don't make any sense in any locale except C, because POSIX no
longer requires collating order.
The regex(7) man page says that [xx-xx] uses ***collating order**::
The regex(7) man page _of which system_? Just because _some_ systems
(like glibc, picking the POS
Eric Blake wrote:
On 05/21/2012 05:42 PM, Linda Walsh wrote:
Only in POSIX 1992 or in the C locale. In POSIX 2001 and POSIX 2008,
and non-C locales, [A-Z] is explicitly undefined,
==
ONLY under POSIX...
You may not believe this, but there are other standards than POSIX.
Mo
On 05/21/2012 05:42 PM, Linda Walsh wrote:
>> POSIX explicitly undefined ranges for all but the C locale. _Other
>> standards_, such as Unicode, are free to add range requirements on top
>> of what POSIX requires, but alas, Unicode collation order does NOT
>> currently specify anything about regu
Andreas Schwab wrote:
Bob Proulx writes:
And lastly I will comment that you are doing quite a bit inside of an
interrupt routine. Typically in a C program it is not safe to perform
any operation that may call malloc() within an interupt service
routine since malloc isn't reentrant. Bash i
Eric Blake wrote:
On 05/21/2012 03:02 PM, Linda Walsh wrote:
the cat was out of the bag. POSIX 2001 had to continue to allow
existing implementations, by stating that range expressions in anything
but the C locale are explicitly undefined.
-
Explicitly undefined?
On 05/21/2012 03:02 PM, Linda Walsh wrote:
>> the cat was out of the bag. POSIX 2001 had to continue to allow
>> existing implementations, by stating that range expressions in anything
>> but the C locale are explicitly undefined.
>
> -
>
>
> Explicitly undefined? Or
On 5/21/12 5:02 PM, Linda Walsh wrote:
> I.e. Unicode does specify ordering, so if your locale is set
> to UTF-8 character encoding, then it is explicitly defined. This would
> seem to be in conflict with unicode -- and any implementation claiming
> to be unicode compatible MUST use unicode o
Eric Blake wrote:
On 05/21/2012 01:51 PM, Linda Walsh wrote:
POSIX is not supposed to be prescriptive -- but **descriptive**...
I can't think of anywhere that a-z or A-Z would have included letters
from the opposite case... so how did POSIX come to *prescribe* that this
be the case... since
On 05/21/2012 01:51 PM, Linda Walsh wrote:
> POSIX is not supposed to be prescriptive -- but **descriptive**...
>
> I can't think of anywhere that a-z or A-Z would have included letters
> from the opposite case... so how did POSIX come to *prescribe* that this
> be the case... since I can't see t
Aharon Robbins wrote:
You'd think unicode would have something to say about collation
order that wouldn't allow such randomness, but maybe not.
It actually makes sense that it doesn't, since Unicode is more or less
a mapping of code points to glyphs, which is language independant. The
rules
On Mon, May 21, 2012 at 03:46:00PM -0400, Chet Ramey wrote:
> Posix says that ranges work the way you are used to if you force the
> traditional ordering using the `C' or `Posix' locale. Take a deep
> breath and use LC_ALL=C in your scripts to avoid depending on whatever
> your OS uses as the def
Chet Ramey wrote:
On 5/21/12 3:37 PM, Linda Walsh wrote:
This is a prime example of Posix being stupid and bad for
computer science.
They take a deterministic behavior and define it to be
non-deterministic and break 1000's of programs.
Try being a little less English-centric.
On 5/21/12 3:37 PM, Linda Walsh wrote:
>
> This is a prime example of Posix being stupid and bad for
> computer science.
>
> They take a deterministic behavior and define it to be
> non-deterministic and break 1000's of programs.
Try being a little less English-centric. Collating o
On 5/21/12 3:27 PM, Aharon Robbins wrote:
> This is why I started the Campaign For Rational Range Interpretation,
> now part of gawk and I believe in the most recent grep also, which
> returns us to the sane days of yesteryear, where [a-z] got only lowercase
> letters and [A-Z] got only uppercase
On 5/21/12 3:27 PM, Aharon Robbins wrote:
>> So which is correct?
>
> Both! Isn't this fun!
What's most fun is having this discussion over and over again, each time as
if it were the first.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita bre
Greg Wooledge wrote:
On Mon, May 21, 2012 at 12:19:26PM -0700, Linda Walsh wrote:
Greg Wooledge wrote:
For instance, on HP-UX 10.20, in the en_US.iso88591 locale:
A a ... B b
Meanwhile, on Debian 6.0, in the en_US.iso88591 locale:
a A ... b B
So which is correct?
Both. Loc
In article ,
Linda Walsh wrote:
>Greg Wooledge wrote:
>
>> On Sun, May 20, 2012 at 11:36:35AM -0700, Linda Walsh wrote:
>
>> For instance, on HP-UX 10.20, in the en_US.iso88591 locale:
>> A a ... B b
>> Meanwhile, on Debian 6.0, in the en_US.iso88591 locale:
>> a A ... b B
>>
>> A
On Mon, May 21, 2012 at 12:19:26PM -0700, Linda Walsh wrote:
> Greg Wooledge wrote:
> >For instance, on HP-UX 10.20, in the en_US.iso88591 locale:
> >A a ... B b
> >Meanwhile, on Debian 6.0, in the en_US.iso88591 locale:
> >a A ... b B
> So which is correct?
Both. Locale collating
On Mon, 21 May 2012, Linda Walsh wrote:
Greg Wooledge wrote:
On Sun, May 20, 2012 at 11:36:35AM -0700, Linda Walsh wrote:
For instance, on HP-UX 10.20, in the en_US.iso88591 locale:
A a ... B b
Meanwhile, on Debian 6.0, in the en_US.iso88591 locale:
a A ... b B
As you can
Greg Wooledge wrote:
On Sun, May 20, 2012 at 11:36:35AM -0700, Linda Walsh wrote:
For instance, on HP-UX 10.20, in the en_US.iso88591 locale:
A a ... B b
Meanwhile, on Debian 6.0, in the en_US.iso88591 locale:
a A ... b B
As you can see, the two en_US.iso88591 implementation
On Sun, May 20, 2012 at 11:36:35AM -0700, Linda Walsh wrote:
> Anyway... so WHY does bash collate this way?
It doesn't. The operating system does. Bash just calls upon the C
library's strcoll(3) routine.
The results vary across operating systems, and even potentially across
locale definitions w
21 matches
Mail list logo
