Problem with special characters

[fekdahl@…]

Writing swedish special characters (??????) doesn't work in Terminal. Nothing appears on screen, except when pressing ?; then it says "(arg: 6)". Using these characters in all other tested apps work fine.

[fekdahl@…]

Screenshot...

[korli]

I did a fix in revision 16496 for 1 byte characters which need option key. I don't know if the bug was about this.

[fekdahl@…]

I haven't tried that revision yet, but it doesn't sound like the same problem since you don't need to press any additional key to type ??? or ??? on swedish keyboards.

[jackburton]

Bug is still showing up. Italian multibyte characters like "?", "?", etc. aren't drawn correctly either.

[korli]

Must be a tty problem, as we write good bytes and read wrong ones. Changing component ...

[korli]

Last comment is wrong : it seems bash hasn't been built multibyte support (yet)

[jackburton]

There is a patch done by mmu_man around. Maybe he even sent it to our mailing list?

[johndrinkwater]

Following on from comment 7, added Fran?ois to CC

[revol@…]

It could be simpler to switch to bash 3.0 right away. It has problems in Zeta re. utf-8 but that's because the glibc in zeta is old. Which glibc do we use btw ?

[nielx]

Move to the proper component.

[nielx]

Bug #1699 is marked as a duplicate of this bug.

[jackburton]

It's a bash problem, though, not Terminal's.

[jackburton]

Interestingly bash 3.2 suffers from the same problem. Maybe it's a (bash) build configuration issue?

[jackburton]

Replying to jackburton:

Interestingly bash 3.2 suffers from the same problem. Maybe it's a (bash) build configuration issue?

Replying to myself: Yes, it's a build configuration issue. Defining HAVE_WCTYPE and HAVE_MBSTATE to 1 enables multibyte support in bash. Doing so, though, triggers a problem: haiku doesn't boot anymore (hangs on INIT: Bootscript started).

[jackburton]

Yes, it's a build configuration issue. Defining HAVE_WCTYPE and HAVE_MBSTATE to 1 enables multibyte support in bash. Doing so, though, triggers a problem: haiku doesn't boot anymore (hangs on INIT: Bootscript started).

Replying to myself, again: It's pretty obvious it doesn't work, since our mbrtowc() method is a no-op.

[jackburton]

depends on #1855.

[jackburton]

Change milestone to R1

[bonefish]

(In #3047) Duplicate of #215.

BTW, please use a small "r" when referring to revisions (i.e. hrev28446 instead of R28446); only then Trac hyperlinks it correctly.

[jackburton]

I added some printfs() in the code, and it seems that, like korli said in a comment, 3 years ago, "Must be a tty problem, as we write good bytes and read wrong ones". I have no idea if bash is involved: IOW: I don't know how the data flow looks like. But in Shell::Write(), the bytes look correct (for the "à" character, it's 0xc3 0xa0). But this sequence never show up in TermParse::_ReadParserBuffer(). Actually, nothing shows up there when I hit this key.

[andreas_dr]

its not a tty problem. i checked the code and did not see any problem with it. it does not show up in TermParse::_ReadParserBuffer() because the shell is interpreting the char not correctly.

[scottmc]

Can someone recheck this one now that wchar fix is in place? Does it have any effect?

[ekdahl]

I checked right after the merging with trunk, and the problem is still there.

[axeld]

Fixed in hrev34150. Of course it was just a readline configuration issue...