2011-08-25, 12:19(-07), Linda Walsh:
[...]
> ` Greg Wooledge wrote:
>> On Wed, Aug 24, 2011 at 06:51:32PM -0700, Linda Walsh wrote:
>>
>>> BTW, Thomas -- what is the Character that comes after 'De' in your
>>> name? I read it as hex '0xc282c2' which doesn't seem to be valid unicode.
>>>
>
On 9/12/11 9:22 AM, Thomas De Contes wrote:
> on the other hand, if there is a way for bash to not display special
> characters on the interactive line,
> i suppose it can be useful to know how to do that in many cases, for example
> if i switch on a new platform, waiting for making special char
Le 25 août 2011 à 15:35, Chet Ramey a écrit :
>>
>> Le 25 août 2011 à 14:17, Chet Ramey a écrit :
>>
so, wcwidth is apple's responsibility, then no libre-software developer
can do anything,
Am I right ?
>>>
>>> To a certain extent, yes. wcwidth is a libc function, and it has a
Thomas De Contes wrote:
Le 25 août 2011 à 14:36, Greg Wooledge a écrit :
On Wed, Aug 24, 2011 at 06:51:32PM -0700, Linda Walsh wrote:
BTW, Thomas -- what is the Character that comes after 'De' in your
name? I read it as hex '0xc282c2' which doesn't seem to be valid unicode.
` Greg Wooledge wrote:
On Wed, Aug 24, 2011 at 06:51:32PM -0700, Linda Walsh wrote:
BTW, Thomas -- what is the Character that comes after 'De' in your
name? I read it as hex '0xc282c2' which doesn't seem to be valid unicode.
RFC 2822 (section 2.2) says that Header Fields in an ema
>
> Le 25 août 2011 à 14:17, Chet Ramey a écrit :
>
> >> so, wcwidth is apple's responsibility, then no libre-software developer
> >> can do anything,
> >> Am I right ?
> >
> > To a certain extent, yes. wcwidth is a libc function, and it has a bug
> > on Mac OS X.
>
> Well, libc is a part of
On Thu, Aug 25, 2011 at 03:09:04PM +0200, Thomas De Contes wrote:
> Well, libc is a part of linux, isn't it ?
libc is the generic name for an implementation of the library of functions
required by various standards, including ISO/ANSI C, POSIX, and so on.
It's usually named libc* and located in /l
Le 25 août 2011 à 14:17, Chet Ramey a écrit :
>> so, wcwidth is apple's responsibility, then no libre-software developer can
>> do anything,
>> Am I right ?
>
> To a certain extent, yes. wcwidth is a libc function, and it has a bug
> on Mac OS X.
Well, libc is a part of linux, isn't it ?
Does
Le 25 août 2011 à 14:36, Greg Wooledge a écrit :
> On Wed, Aug 24, 2011 at 06:51:32PM -0700, Linda Walsh wrote:
>> BTW, Thomas -- what is the Character that comes after 'De' in your
>> name? I read it as hex '0xc282c2' which doesn't seem to be valid unicode.
(it is NBSP (for address book))
>
On Wed, Aug 24, 2011 at 06:51:32PM -0700, Linda Walsh wrote:
> BTW, Thomas -- what is the Character that comes after 'De' in your
> name? I read it as hex '0xc282c2' which doesn't seem to be valid unicode.
RFC 2822 (section 2.2) says that Header Fields in an email must be
composed of US-ASCII ch
> so, wcwidth is apple's responsibility, then no libre-software developer can
> do anything,
> Am I right ?
To a certain extent, yes. wcwidth is a libc function, and it has a bug
on Mac OS X. I will have a workaround in the next readline release.
Chet
--
``The lyf so short, the craft so long
Chet Ramey wrote:
In yours, however, it is 0x65 0xcc 0x81 which is U+0065 LATIN SMALL
LETTER E followed by U+0301 COMBINING ACUTE ACCENT.
That's not valid UTF-8, since UTF-8 requires that the shortest sequence
be used to encode a character.
This is exactly true...
Valid UTF-8 is anythi
Le 16 mai 2011 à 17:02, Chet Ramey a écrit :
> On 5/9/11 10:46 AM, Thomas De Contes wrote:
>> 1
>> - execute
>> PS1="&# $PS1"
>> - drag & drop the file with the accent
>> - use "top arrow" and "bottom arrow" to move in the history :
>> at each time you move on the line containing an accent, it ea
Type: i386-apple-darwin10.7.0
>
> Bash Version: 4.2
> Patch Level: 8
> Release Status: release
>
>
> Description:
>
> 1
> when i do
> PS1="&# $PS1"
> then I have problems since there is some accents in my command lines :
> http://cjoint.com
Chet Ramey writes:
> That's a non sequitor. My point is that, as I read it, UTF-8 requires the
> use of the shortest sequence that can represent a particular character.
The character is U+0301, and the shorted sequence is 0xcc 0x81.
> In this case, that means that U+00E9 must be used to repres
On 5/15/11 6:16 PM, Chet Ramey wrote:
> The other difference is that drag-and-drop on Mac OS X (at least dropping
> from the finder) produces full pathnames. I was able to reproduce display
> problems (which I haven't yet investigated) using that, but not using
> tab completion in the way you did
On 5/15/11 6:38 PM, Andreas Schwab wrote:
> Chet Ramey writes:
>
>> On 5/10/11 9:17 AM, Greg Wooledge wrote:
>>
>>> In yours, however, it is 0x65 0xcc 0x81 which is U+0065 LATIN SMALL
>>> LETTER E followed by U+0301 COMBINING ACUTE ACCENT.
>>
>> That's not valid UTF-8, since UTF-8 requires that t
Chet Ramey writes:
> On 5/10/11 9:17 AM, Greg Wooledge wrote:
>
>> In yours, however, it is 0x65 0xcc 0x81 which is U+0065 LATIN SMALL
>> LETTER E followed by U+0301 COMBINING ACUTE ACCENT.
>
> That's not valid UTF-8, since UTF-8 requires that the shortest sequence
> be used to encode a character
s COMBINING ACUTE ACCENT thing properly, the
> only indicator that you are in a multi-byte character comes with the
> *second* byte, so you have to backtrack. What idiot thought this up?
It's a way to provide a general mechanism for combining characters. Most
locales have unicode/utf-8 c
On 5/10/11 9:17 AM, Greg Wooledge wrote:
> In yours, however, it is 0x65 0xcc 0x81 which is U+0065 LATIN SMALL
> LETTER E followed by U+0301 COMBINING ACUTE ACCENT.
>
> Perhaps Bash does not know how to interpret COMBINING ACUTE ACCENT which
> follows a letter...?
>
> I'm not intimately familiar
Perhaps the wcwidth function is broken on MacOS.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Tue, May 10, 2011 at 04:47:29AM +0200, Thomas De Contes wrote:
> tDeContes-fixe:~ thomas$ echo "$PS1"
> + echo '\h:\W \u\$ '
> \h:\W \u\$
> if i do not
> PS1="&# $PS1"
> then i don't have the problem described in 1
I am not able to reproduce this in my environment. I'm using Debian 6.0
on i3
Le 9 mai 2011 à 20:21, Greg Wooledge a écrit :
> On Mon, May 09, 2011 at 04:46:14PM +0200, Thomas De Contes wrote:
>> Description:
>>
>> 1
>> when i do
>> PS1="&# $PS1"
>> then I have problems since there is some accents in my command lin
On Mon, May 09, 2011 at 04:46:14PM +0200, Thomas De Contes wrote:
> Description:
>
> 1
> when i do
> PS1="&# $PS1"
> then I have problems since there is some accents in my command lines :
What is the value of PS1 before you prepend ampersand-hash-space to it?
Wh
pipe -O2 -arch x86_64
uname output: Darwin tDeContes-fixe.local 10.7.0 Darwin Kernel Version 10.7.0:
Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386
Machine Type: i386-apple-darwin10.7.0
Bash Version: 4.2
Patch Level: 8
Release Status: release
Description:
1
when i d
25 matches
Mail list logo
