Re: Fix u32toutf8 so it encodes values > 0xFFFF correctly.

2012-02-22 Thread Eric Blake
On 02/22/2012 10:02 PM, Linda Walsh wrote: > > > Eric Blake wrote: > >> >> Don't think of it as 'wide-int', rather, think of it as 'the integral >> type that both contains wchar_t and WEOF'. You cannot write 'signed >> wint_t' nor 'unsigned 'wint_t'. > > > --- > ?? You say don't think of it t

Re: Fix u32toutf8 so it encodes values > 0xFFFF correctly.

2012-02-22 Thread John Kearney
And on the up side if they do ever give in and allow registration of family name characters we may get a wchar_t, schar_t lwchar_t and a llwchar_t :) just imagine a variable length 64bit char system. Everything from Sumerian to Klingon in Unicode, though I think they already are, though not offici

Re: Fix u32toutf8 so it encodes values > 0xFFFF correctly.

2012-02-22 Thread Linda Walsh
Eric Blake wrote: Don't think of it as 'wide-int', rather, think of it as 'the integral type that both contains wchar_t and WEOF'. You cannot write 'signed wint_t' nor 'unsigned 'wint_t'. --- ?? You say don't think of it that way, but unless I missed something, just like wchar stood for '

Re: Fix u32toutf8 so it encodes values > 0xFFFF correctly.

2012-02-22 Thread Eric Blake
On 02/22/2012 07:43 PM, John Kearney wrote: > ^ caviot you can represent the full 0x10 in UTF-16, you just need 2 > UTF-16 characters. check out the latest version of unicode.c for an > example how. Yes, and Cygwin actually does this. A strict reading of POSIX states that wchar_t must be wide

Re: Fix u32toutf8 so it encodes values > 0xFFFF correctly.

2012-02-22 Thread John Kearney
^ caviot you can represent the full 0x10 in UTF-16, you just need 2 UTF-16 characters. check out the latest version of unicode.c for an example how. On 02/22/2012 11:32 PM, Eric Blake wrote: > On 02/22/2012 03:01 PM, Linda Walsh wrote: >> My question had to do with an unqualified wint_t no

Re: Fix u32toutf8 so it encodes values > 0xFFFF correctly.

2012-02-22 Thread Eric Blake
On 02/22/2012 03:01 PM, Linda Walsh wrote: > My question had to do with an unqualified wint_t not > unsigned wint_t and what platform existed where an 'int' type or > wide-int_t, was, without qualifiers, unsigned. I still would like > to know -- and posix allows int/wide-ints to be unsigned wi

Re: Fix u32toutf8 so it encodes values > 0xFFFF correctly.

2012-02-22 Thread Linda Walsh
Eric Blake wrote: On 02/22/2012 05:19 AM, Linda Walsh wrote: Eric Blake wrote: Not only can wchar_t can be either signed or unsigned, you also have to worry about platforms where it is only 16 bits, such as cygwin; on the other hand, wint_t is always 32 bits, but you still have the issue

Re: Initial test code for \U

2012-02-22 Thread Eric Blake
On 02/22/2012 12:55 PM, Chet Ramey wrote: > On 2/21/12 5:07 PM, John Kearney wrote: >> >> Initial code for testing \u functionality. > > Thanks; this is really good work. In the limited testing I've done, > ja_JP.SHIFT_JIS is rare and C.UTF-8 doesn't exist anywhere. C.UTF-8 exists on Cygwin. Bu

Re: Initial test code for \U

2012-02-22 Thread Chet Ramey
On 2/21/12 5:07 PM, John Kearney wrote: > > Initial code for testing \u functionality. Thanks; this is really good work. In the limited testing I've done, ja_JP.SHIFT_JIS is rare and C.UTF-8 doesn't exist anywhere. ja_JP.SJIS is a somewhat less rare substitute for the former, and en_US.UTF-8 se

Re: printf "%q" "~" not escaped?

2012-02-22 Thread Chet Ramey
On 2/22/12 2:47 AM, John Kearney wrote: > Bash Version: 4.2 > Patch Level: 10 > Release Status: release > > Description: > printf "%q" "~" not escaped? > > which means that this > eval echo $(printf "%q" "~") > results in your home path not a ~ > unlike > eval echo $(printf "%q" "*") > > as far

Re: Fix u32toutf8 so it encodes values > 0xFFFF correctly.

2012-02-22 Thread John Kearney
On 02/22/2012 01:59 PM, Eric Blake wrote: > On 02/22/2012 05:19 AM, Linda Walsh wrote: >> >> >> Eric Blake wrote: >> >> >>> Not only can wchar_t can be either signed or unsigned, you also have to >>> worry about platforms where it is only 16 bits, such as cygwin; on the >>> other hand, wint_t is al

Re: Fix u32toutf8 so it encodes values > 0xFFFF correctly.

2012-02-22 Thread Eric Blake
On 02/22/2012 05:19 AM, Linda Walsh wrote: > > > Eric Blake wrote: > > >> Not only can wchar_t can be either signed or unsigned, you also have to >> worry about platforms where it is only 16 bits, such as cygwin; on the >> other hand, wint_t is always 32 bits, but you still have the issue that

Re: Fix u32toutf8 so it encodes values > 0xFFFF correctly.

2012-02-22 Thread Linda Walsh
Eric Blake wrote: Not only can wchar_t can be either signed or unsigned, you also have to worry about platforms where it is only 16 bits, such as cygwin; on the other hand, wint_t is always 32 bits, but you still have the issue that it can be either signed or unsigned. What platform uses

Re: Process group id of first command in command substitution (bash4 vs bash3)

2012-02-22 Thread Roman Rakus
On 02/20/2012 10:57 PM, Chet Ramey wrote: I'm not sure if it's a bug or not, but there is change between old bash 3.2 and bash 4.2. When you run a script: set -m $(sleep 1; sleep 2) in bash 4.2 the first sleep has same group id as parent shell. However in bash 3.2 it has different group id. Is