This is the mail archive of the
mailing list for the Cygwin project.
Re: [ANNOUNCEMENT] Updated: Cygwin 2.6.1-1
- From: Steven Penny <svnpenn at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Wed, 11 Jan 2017 04:51:59 -0800 (PST)
- Subject: Re: [ANNOUNCEMENT] Updated: Cygwin 2.6.1-1
- Authentication-results: sourceware.org; auth=none
On Tue, 10 Jan 2017 23:49:16, Brian Inglis wrote:
> Both of which run under the cmd console
No, they dont. They both run under the Console Window Host.
> You can look up which characters are displayed using Alt-numpad-digits
> at https://en.wikipedia.org/wiki/Code_page_437 or in the selected code
> page using Alt-numpad-0-digits at Code_page_nnn or Windows_nnnn.
Why do I need to do this? I already know that it is capital omega.
> On top of that is added the Windows locale mapping to Cygwin locale and
> character set, plus readline settings used by bash in ~/.inputrc, which
> may change input interpretation.
Again, did you try this or are you just guessing? If so what inputrc value needs
to be set?
> Type locale to see what locale Cygwin thinks you are running.
> Documentation available is at:
> which documents the default as C.UTF-8 (ASCII) unless LC_ALL, LC_CTYPE,
> or LANG env vars are set to change the locale and/or char set.
Again, did you try this or are you just guessing? If so what value needs to be
> You may have to chcp n in Cygwin.bat to get correct character output,
> either 437 for US, 850 for English, 65001 for UTF-8, others from
> above reference for other locales and char sets.
Again, no because cmd.exe works fine even with 437.
> It is an alternative input method for Unicode characters which does
> not seem to be supported with bash under cmd configured with default
> code pages, but is in mintty and elsewhere in Windows, which avoids
> having to pop up CharMap and search when you know the Unicode code
> point wanted.
Again, hex input is not needed, cmd.exe handles Alt-decimal just fine.
> Most Windows monospace fonts do not support most new Unicode characters,
> but fallback fonts can be configured in the registry to provide missing
> glyphs, given available fonts which support the glyphs, and code page
> 65001/char set UTF-8 which supports the Unicode character set.
Again, no font is needed as this character is already supported though existing
> Mea culpa, having configured everything I can in Windows, Cygwin, and
> apps to support Unicode/UTF-8 character sets, with appropriate fonts
> and fallbacks, I forget the limitations and problems with OEM code
> pages which caused me to make that effort, indeed that people, apps,
> or systems still use those code pages implicitly.
Somehow you managed to make a nearly 400 word reply without adding anything to
your previous post. I am actually impressed. Please going forward post
suggestions that you have actually tried and fix the problem at hand, thank you.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple