zsh-users
 help / color / mirror / code / Atom feed
From: Duncan Sinclair <sinclair@dis.strath.ac.uk>
To: zsh-users@math.gatech.edu
Subject: Re: German Umlauts still dont work
Date: Fri, 04 Jul 1997 13:16:56 +0100	[thread overview]
Message-ID: <376.868018616@dis.strath.ac.uk> (raw)
In-Reply-To: Your message of "Fri, 04 Jul 1997 05:39:35 +0200."


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.


             reply	other threads:[~1997-07-04 12:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-07-04 12:16 Duncan Sinclair [this message]
1997-07-08 13:32 ` Uli Zappe
  -- strict thread matches above, loose matches on Subject: below --
1997-07-04  3:39 Wolfgang Hukriede
1997-07-08 13:23 ` Uli Zappe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=376.868018616@dis.strath.ac.uk \
    --to=sinclair@dis.strath.ac.uk \
    --cc=zsh-users@math.gatech.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).