Opened 13 years ago

Closed 10 years ago

#215 closed bug (fixed)

Problem with special characters

Reported by: fekdahl@… Owned by: nobody
Priority: high Milestone: R1
Component: Applications/Command Line Tools Version: R1/Development
Keywords: Cc: diver, revol@…
Blocked By: #1855 Blocking: #3047
Has a Patch: no Platform: All

Description

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.

Attachments (1)

DataTranslations.png (61.2 KB) - added by fekdahl@… 13 years ago.
Screenshot…

Download all attachments as: .zip

Change History (33)

Changed 13 years ago by fekdahl@…

Attachment: DataTranslations.png added

Screenshot...

comment:1 Changed 13 years ago by sikosis

Status: newassigned

comment:2 Changed 13 years ago by 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.

comment:3 Changed 13 years ago by 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.

comment:4 Changed 13 years ago by jackburton

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

comment:5 Changed 13 years ago by axeld

Status: assignednew

comment:6 Changed 13 years ago by axeld

Owner: changed from sikosis to axeld

comment:7 Changed 13 years ago by korli

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

comment:8 Changed 13 years ago by korli

Component: ApplicationsKernel

comment:9 Changed 13 years ago by korli

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

comment:10 Changed 13 years ago by korli

Component: KernelApplications

comment:11 Changed 13 years ago by jackburton

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

comment:12 Changed 13 years ago by diver

Cc: diver added

comment:13 Changed 13 years ago by korli

bug_group: developers

comment:14 Changed 13 years ago by johndrinkwater

Cc: revol@… added

comment:15 Changed 13 years ago by johndrinkwater

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

comment:16 Changed 13 years ago by 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 ?

comment:17 Changed 12 years ago by nielx

Component: - Applications- Applications/Terminal
Owner: changed from axeld to jackburton
Platform: All

Move to the proper component.

comment:18 Changed 11 years ago by nielx

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

comment:19 Changed 11 years ago by jackburton

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

comment:20 Changed 11 years ago by jackburton

Milestone: R1R1/alpha1

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

comment:21 in reply to:  20 ; Changed 11 years ago by 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).

comment:22 in reply to:  21 Changed 11 years ago by 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.

comment:23 Changed 11 years ago by jackburton

depends on #1855.

comment:24 Changed 11 years ago by korli

Blocked By: 1855 added

comment:25 Changed 11 years ago by jackburton

Milestone: R1/alpha1R1

Change milestone to R1

comment:26 Changed 11 years ago by bonefish

Blocking: 3047 added

(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.

comment:27 Changed 11 years ago by 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.

comment:28 Changed 10 years ago by andreas_dr

Version: R1 development

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.

comment:29 Changed 10 years ago by scottmc

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

comment:30 Changed 10 years ago by ekdahl

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

comment:31 Changed 10 years ago by axeld

Component: Applications/TerminalApplications/Command Line Tools
Owner: changed from jackburton to nobody
Version: R1/pre-alpha1R1/Development

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

comment:32 Changed 10 years ago by axeld

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.