[101464] trunk/dports/_resources/port1.0/group/ compiler_blacklist_versions-1.0.tcl

[Michael Dickens]

On Jan 24, 2013, at 9:46 AM, Rainer Müller <raimue at 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. 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
}}}
Maybe my xterm is ``special''? - MLD