Date:	Tue, 14 Mar 2000 09:44:36 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Dieter Buerssner <buers AT gmx DOT de>
cc:	djgpp AT delorie DOT com
Subject:	Re: bash 2.03 / german umlauts
In-Reply-To:	<8aj6e1$3qe1t$1@fu-berlin.de>
Message-ID:	<Pine.SUN.3.91.1000314094146.4527D-100000@is>
MIME-Version:	1.0
X-MIME-Autoconverted:	from QUOTED-PRINTABLE to 8bit by delorie.com id CAA07324
Reply-To:	djgpp AT delorie DOT com
Errors-To:	dj-admin AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On 13 Mar 2000, Dieter Buerssner wrote:

> I have not looked into the termios code. But is there a reason,
> that it uses the BIOS?

Yes, there are good reasons.  Without working on the BIOS level, you
cannot support some of the termios features, like suppressing the
echo, changing the characters which have special meaning, mapping CR
to NL and vice versa, etc.

> Does it hook the keyboard interrupt directly?

No, it uses function 0 of Int 16h.

> With the following program:
[snip]
> When I type either a-Umlaut ("a, ä for those who can read it),
> or Alt-132 I get
> 
> key 0x84: '"a' 
> 
> So it seems, that national keyboard support is available at the
> BIOS level.

Yes, sorry, I think was mistaken.  You are right, BIOS function 0 does 
know about the national keyboard.  (I was thinking about scan codes, not 
characters.)

So I guess I have no idea why does Bash refuse to see the Latin
characters.

> In bash, there will be a beep in either case and no screen output.
> (And in gdb 4.18 as well)

I think that's because Bash and GDB both use the readline library,
which by default interpret the 8th bit as the Meta bit.  I don't know
if you can turn that off.

But the interesting aspect is that Bash reacts differently in your case.
The original poster cannot get German characters by using the Alt-numeric 
method.  Do you have any idea why? 

- Raw text -