Opened 14 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@… 14 years ago.
Screenshot…

Download all attachments as: .zip

Change History (33)

by fekdahl@…, 14 years ago

Attachment: DataTranslations.png added

Screenshot...

comment:1 by sikosis, 14 years ago

Status: newassigned

comment:2 by korli, 14 years ago

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 by fekdahl@…, 14 years ago

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 by jackburton, 14 years ago

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

comment:5 by axeld, 14 years ago

Status: assignednew

comment:6 by axeld, 14 years ago

Owner: changed from sikosis to axeld

comment:7 by korli, 14 years ago

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

comment:8 by korli, 14 years ago

Component: ApplicationsKernel

comment:9 by korli, 14 years ago

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

comment:10 by korli, 14 years ago

Component: KernelApplications

comment:11 by jackburton, 14 years ago

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

comment:12 by diver, 13 years ago

Cc: diver added

comment:13 by korli, 13 years ago

bug_group: developers

comment:14 by johndrinkwater, 13 years ago

Cc: revol@… added

comment:15 by johndrinkwater, 13 years ago

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

comment:16 by revol@…, 13 years ago

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 by nielx, 12 years ago

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

Move to the proper component.

comment:18 by nielx, 12 years ago

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

comment:19 by jackburton, 12 years ago

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

comment:20 by jackburton, 12 years ago

Milestone: R1R1/alpha1

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

in reply to:  20 ; comment:21 by jackburton, 12 years ago

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

in reply to:  21 comment:22 by jackburton, 12 years ago

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 by jackburton, 12 years ago

depends on #1855.

comment:24 by korli, 11 years ago

Blocked By: 1855 added

comment:25 by jackburton, 11 years ago

Milestone: R1/alpha1R1

Change milestone to R1

comment:26 by bonefish, 11 years ago

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 by jackburton, 11 years ago

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 by andreas_dr, 10 years ago

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 by scottmc, 10 years ago

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

comment:30 by ekdahl, 10 years ago

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

comment:31 by axeld, 10 years ago

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 by axeld, 10 years ago

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