From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8531 invoked from network); 4 Jul 1997 12:27:52 -0000 Received: from euclid.skiles.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 4 Jul 1997 12:27:52 -0000 Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id IAA08259; Fri, 4 Jul 1997 08:13:21 -0400 (EDT) Resent-Date: Fri, 4 Jul 1997 08:12:58 -0400 (EDT) To: zsh-users@math.gatech.edu Subject: Re: German Umlauts still dont work In-reply-to: Your message of "Fri, 04 Jul 1997 05:39:35 +0200." Date: Fri, 04 Jul 1997 13:16:56 +0100 Message-ID: <376.868018616@dis.strath.ac.uk> From: Duncan Sinclair Resent-Message-ID: <"NSndh2.0.e02.AZElp"@euclid> Resent-From: zsh-users@math.gatech.edu X-Mailing-List: archive/latest/933 X-Loop: zsh-users@math.gatech.edu X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Wolfgang Hukriede writes: > >whereas: > > isprint(c) == c>=040 && c<=0176 > >on any of the systems I checked. Fwiw, on neither of them (OSF3.2, SunOs >4.1.3, Linux 2.0.27, for Nextstep we knew this) the behaviour of isprint() >or iscntrl() obeyes to the locale settings, someone might say, these >machines all lack proper setup? > On my SunOS 4.1.3's /usr/include/ctype.h: #define isprint(c) ((_ctype_+1)[c]&(_P|_U|_L|_N|_B)) Where "_ctype_[]" array is the contents of the locale/LC_CTYPE file that's current, and the "_P", etc. flags are bit codes for the different types a character that the ctype routines need to know about. I have "LC_CTYPE=iso_8859_1" in my environment, and it works as advertised. I think the problem needs to be defined better. Are your umlauts dissappearing entirely (a zsh problem) or are they being meta-ized (\M-? - an OS problem), or perhaps they are coming through, but your terminal emulator can't display them correctly (a S.O.L. problem)? A good operating system would have locale settings such as "C", "iso_*", and any non-standard charset it used, such as, "next", "mac", "ebcidic" or whatever. Then you would set your LC_CTYPE variable according to what character set you are using today. Now if NextStep can only do "C" (isprint()) or "next" (NXisprint), then that's fine if that's all your using. But if your terminal emulator can only do iso_8859_1, like xterm, then your screwed when it comes to displaying any non-ascii nextstep characters. (Unless there's a specially hacked Next xterm that understands its charset?) I would guess this isn't the problem, or else you wouldn't be complaining just about zsh, but about everything. If you think it's a zsh problem, can zsh glob filenames with these characters properly: "echo *"? Can you type these characters, is the problem only in completion? Do other programs, such as "ls" or "less" have problems? I hope this helps the discussion. Duncan.