On 2013-01-24 16:29, Michael Dickens wrote:
> On Jan 24, 2013, at 9:46 AM, Rainer Müller <rai...@macports.org> wrote:
>> It's probably not a problem for most users with a recent enough terminal
>> emulator that supports UTF-8. Actually one would have to check by locale
>> environment or by other means whether support for UTF-8 is available... Not
>> sure if this is worth the effort. I tried with xterm within XQuartz and it
>> seems to work for me (by checking with 'port info graphite2', which includes
>> smart quotes). I am using LC_ALL="en_US.UTF-8". I experimented with some
>> different values, but found no way to break it.
>
> Interesting. I'm using the (I think) latest release of XQuartz from
> MacOSForge [from "About X11": "XQuartz 2.7.4 (xorg-server 1.13.0)"], and
> the (I think) xterm provided by it: "which xterm" returns
> "/usr/X11R6/bin/xterm", and "xterm -help" returns "XTerm(281)" if that
> makes any difference. I do not have Apple's X11.app installed.
It's /opt/X11/bin/xterm for me, but I guess /usr/X11R6 on your system is
a symlink to that anyway. I use the same versions on Mac OS X 10.8
Mountain Lion.
> I tried
> "port info graphite2" and it locks the terminal at the first smart
> quote. I tried
> {{{
> export LC_ALL="en_US.UTF-8"
> }}}
> and then the info command with the same result. All of the ~/.Xdefaults
> for xterm are color related, not encoding; so, those shouldn't make a
> difference. My shell environment is pretty normal; the only variables I
> see that might have an impact are:
> {{{
> __CF_USER_TEXT_ENCODING=0x1F6:0:0
> XTERM_LOCALE=C
> }}}
>From the xterm window:
$ env |grep -E 'XTERM|__CF'
XTERM_SHELL=/opt/local/bin/bash
__CF_USER_TEXT_ENCODING=0x1F5:0:0
XTERM_LOCALE=en_US.UTF-8
XTERM_VERSION=XTerm(281)
I don't know where XTERM_LOCALE comes from, but from the name it sounds
like that could be the culprit.
Rainer
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
