Date: Tue, 14 Mar 2000 09:44:36 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Dieter Buerssner cc: djgpp AT delorie DOT com Subject: Re: bash 2.03 / german umlauts In-Reply-To: <8aj6e1$3qe1t$1@fu-berlin.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit 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 Precedence: bulk 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?