12345678901234567890123456789012345678901234567890123456789012345678901234567890
Greg Wooledge wrote:
On Fri, May 20, 2011 at 12:31:31AM -0700, Linda Walsh wrote:
1) use of of the \u and \U escape sequences
in the format string (16 and 32 bit Unicode values).
This isn't even a sen
On 05/20/2011 02:30 PM, Linda Walsh wrote:
> i.e. it's showing me a 16-bit value: 0x203c, which I thought would be the
> wide-char value for the double-exclamation. Going from the wchar
> definition
> on NT, it is a 16-bit value. Perhaps it is different under POSIX? but
> 0x203c taken as 32 bits
Andreas Schwab wrote:
Linda Walsh writes:
2) It doesn't handle the "%lc" conversion to print out wide
characters. To demonstrate this I created a wide char for a
double exclamation mark U+203C, using a=$'0x3c\0x20' and then
That's not a wide character, that's a four character string.
---
Pierre Gaston wrote:
On Fri, May 20, 2011 at 10:31 AM, Linda Walsh wrote:
It appears printf in bash doesn't support unicode
characters in a couple of ways:
1) use of of the \u and \U escape sequences
in the format string (16 and 32 bit Unicode values).
$ printf '%s: \u6444\n' $
On 5/20/11 12:10 PM, Eric Blake wrote:
> On 05/20/2011 09:33 AM, Chet Ramey wrote:
>>> Well, that's rather all over the place, but yes, it does seem like bash
>>> was the buggiest of the lot, compared to other shells. Interactively, I
>>> tested:
>>>
>>> readonly x=1
>>> case 1 in $((x++)) ) echo
On 05/20/2011 09:33 AM, Chet Ramey wrote:
>> Well, that's rather all over the place, but yes, it does seem like bash
>> was the buggiest of the lot, compared to other shells. Interactively, I
>> tested:
>>
>> readonly x=1
>> case 1 in $((x++)) ) echo hi1 ;; *) echo hi2; esac
>> echo $x.$?
>>
>> ba
On 5/19/11 6:09 PM, Eric Blake wrote:
> [adding bug-bash]
>
> On 05/16/2011 07:23 PM, Wayne Pollock wrote:
>> (While cleaning up the standard for case statement, consider that it is
>> currently
>> unspecified what should happen if an error occurs during the expansion of the
>> patterns; as expan
On Fri, May 20, 2011 at 03:29:59PM +0200, Ralf Goertz wrote:
> > In bash 4.2, on a Debian 6.0 box with a UTF-8 locale, printf '\u203c\n'
> I am not Linda but in my setting (4.1.10(1)-release) under linux 64bit I
> have
>
> $ printf "\u203c\n"
> \u203c
It it a bash 4.2 feature; it does not work
On 5/20/11 3:31 AM, Linda Walsh wrote:
>
> It appears printf in bash doesn't support unicode
> characters in a couple of ways:
>
> 1) use of of the \u and \U escape sequences
> in the format string (16 and 32 bit Unicode values).
Bash-4.2 added support for the \u and \U format string
Greg Wooledge wrote:
> On Fri, May 20, 2011 at 12:31:31AM -0700, Linda Walsh wrote:
>> 1) use of of the \u and \U escape sequences
>> in the format string (16 and 32 bit Unicode values).
>
> This isn't even a sentence. What bash command did you execute, and
> what did it do, and what
On Fri, May 20, 2011 at 12:31:31AM -0700, Linda Walsh wrote:
> 1) use of of the \u and \U escape sequences
> in the format string (16 and 32 bit Unicode values).
This isn't even a sentence. What bash command did you execute, and
what did it do, and what did you expect it to do?
In ba
Linda Walsh writes:
> 2) It doesn't handle the "%lc" conversion to print out wide
> characters. To demonstrate this I created a wide char for a
> double exclamation mark U+203C, using a=$'0x3c\0x20' and then
That's not a wide character, that's a four character string. Since
there is no way to
On Fri, May 20, 2011 at 10:31 AM, Linda Walsh wrote:
>
> It appears printf in bash doesn't support unicode
> characters in a couple of ways:
>
> 1) use of of the \u and \U escape sequences
> in the format string (16 and 32 bit Unicode values).
$ printf '%s: \u6444\n' $BASH_VERSION
4.2
It appears printf in bash doesn't support unicode
characters in a couple of ways:
1) use of of the \u and \U escape sequences
in the format string (16 and 32 bit Unicode values).
2) It doesn't handle the "%lc" conversion to print out wide
characters. To demonstrate this I created a
14 matches
Mail list logo
