Re: Advice on setting Cygwin build parameters for OpenSC.
Thank you for the feedback. WND would be _WIN32 builds. Regards, Darren -- Sent from: http://cygwin.1069669.n5.nabble.com/Cygwin-list-f3.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin fails to utilize Unicode replacement character
On Wed, 5 Sep 2018 22:14:59, Corinna Vinschen wrote: OTOH, in my testing this only occurs for DejaVu Sans Mono. I installed Liberation Mono and Noto Mono as well and the above problem never occurs with them. Weird. I'm about to let this slip as a font bug. as you prob know ive been testing on W7. i found a W10 virtual machine here: http://developer.microsoft.com/microsoft-edge/tools/vms but it requires 4GB RAM just for the image. since i only have 4GB total on my system the image wont load into virtualbox. i can see about upgrading my system - but i wont bother if you are intent on wiping your hands of this anyway let me know - thanks -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: handling invalid user/groups (was incompat in cygwin choice of using '+' as domain and user separator.)
On 9/5/2018 1:03 AM, Corinna Vinschen wrote: No, I deliberately removed it from the released version to tease you. Meanie!!! :-) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why does -std=c++11 hide certain function calls
On Wed, 5 Sep 2018 at 14:41, Brian Inglis wrote: > _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _POSIX_SOURCE" Relavent xkcd - https://xkcd.com/927/ -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Odd email symptoms (was Re: handling invalid user/groups)
Thanks for your reply, it's not so much a problem for me, just that when I have some email problem, I often need someone else to point it out to me, as from my perspective, everything is working fine! :-) On 9/5/2018 4:30 AM, Andrey Repin wrote: Greetings, L A Walsh! p.s. -- some "FYI" stuff about your email: when i respond to one of your emails, I get two (2) "To:" entries -- both to cygwin@cygwin.com. I think it might be because the emails from you contain two 'Mail-Followup-To:' lines -- see below**. They are added by list software. Your email client is expected to sort it out and only include unique addresses. It does for most things, but not for 'Mail-Followup-To'. Never seen it on anyone else's email... Even if not, the first MTA you submit your message to should do that. --- Really?... so sendmail should strip off duplicate addresses. I wasn't aware of that. I'll have to try it. Also, I don't get your message included in a response (because it is in a separate attachment. Is that intentional? No, it's your weird mail agent failing to parse a signed email. I see others who sign their email, but hers is the only one that comes through in an attachment. So wondering why her email in particular comes through that way. My "weird" Thunderbird mail agent...h...it may be old, but first time I've heard Tbird called weird. -linda -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[newlib-cygwin] Cygwin: Bump DLL version to 2.11.2
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=9bbda85e27ee9d2d1ab7104b3a07f12ce7b393ce commit 9bbda85e27ee9d2d1ab7104b3a07f12ce7b393ce Author: Corinna Vinschen Date: Wed Sep 5 13:02:09 2018 +0200 Cygwin: Bump DLL version to 2.11.2 Signed-off-by: Corinna Vinschen Diff: --- winsup/cygwin/include/cygwin/version.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/winsup/cygwin/include/cygwin/version.h b/winsup/cygwin/include/cygwin/version.h index 5a53a1d..0eede79 100644 --- a/winsup/cygwin/include/cygwin/version.h +++ b/winsup/cygwin/include/cygwin/version.h @@ -11,7 +11,7 @@ details. */ changes to the DLL and is mainly informative in nature. */ #define CYGWIN_VERSION_DLL_MAJOR 2011 -#define CYGWIN_VERSION_DLL_MINOR 1 +#define CYGWIN_VERSION_DLL_MINOR 2 /* Major numbers before CYGWIN_VERSION_DLL_EPOCH are incompatible. */
[newlib-cygwin] Cygwin: console: improve replacement char algorithm
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=bf8aabe830d215f13e690b21a682fc37aeb8752c
commit bf8aabe830d215f13e690b21a682fc37aeb8752c
Author: Corinna Vinschen
Date: Wed Sep 5 23:39:25 2018 +0200
Cygwin: console: improve replacement char algorithm
Try various Unicode characters which may be used as a replacement
character in case an invalid character has to be printed.
Current list is 0xfffd "REPLACEMENT CHARACTER", 0x25a1 "WHITE SQUARE",
and 0x2592 "MEDIUM SHADE" in that order.
Additionally workaround a problem with some fonts (namely DejaVu
Sans Mono) which are returned wit ha broken fontname with trailing
stray characters.
Signed-off-by: Corinna Vinschen
Diff:
---
winsup/cygwin/autoload.cc | 7 +++
winsup/cygwin/fhandler_console.cc | 95 +--
2 files changed, 99 insertions(+), 3 deletions(-)
diff --git a/winsup/cygwin/autoload.cc b/winsup/cygwin/autoload.cc
index f71abe8..4fac3e3 100644
--- a/winsup/cygwin/autoload.cc
+++ b/winsup/cygwin/autoload.cc
@@ -640,6 +640,12 @@ LoadDLLfunc (LsaRegisterLogonProcess, 12, secur32)
LoadDLLfunc (SHGetDesktopFolder, 4, shell32)
+LoadDLLfunc (CreateFontW, 56, gdi32)
+LoadDLLfunc (DeleteObject, 4, gdi32)
+LoadDLLfunc (EnumFontFamiliesExW, 20, gdi32)
+LoadDLLfunc (GetGlyphIndicesW, 20, gdi32)
+LoadDLLfunc (SelectObject, 8, gdi32)
+
LoadDLLfunc (CloseClipboard, 0, user32)
LoadDLLfunc (CloseDesktop, 4, user32)
LoadDLLfunc (CloseWindowStation, 4, user32)
@@ -651,6 +657,7 @@ LoadDLLfunc (DispatchMessageW, 4, user32)
LoadDLLfunc (EmptyClipboard, 0, user32)
LoadDLLfunc (EnumWindows, 8, user32)
LoadDLLfunc (GetClipboardData, 4, user32)
+LoadDLLfunc (GetDC, 4, user32)
LoadDLLfunc (GetForegroundWindow, 0, user32)
LoadDLLfunc (GetKeyboardLayout, 4, user32)
LoadDLLfunc (GetMessageW, 16, user32)
diff --git a/winsup/cygwin/fhandler_console.cc
b/winsup/cygwin/fhandler_console.cc
index b4674b8..c654d66 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -1971,14 +1971,103 @@ bad_escape:
}
}
+#define NUM_REPLACEMENT_CHARS 3
+
+static const wchar_t replacement_char[NUM_REPLACEMENT_CHARS] =
+{
+ 0xfffd, /* REPLACEMENT CHARACTER */
+ 0x25a1, /* WHITE SQUARE */
+ 0x2592 /* MEDIUM SHADE */
+};
+/* nFont member is always 0 so we have to use the facename. */
+static WCHAR cons_facename[LF_FACESIZE];
+static int rp_char_idx;
+static HDC cdc;
+
+static int CALLBACK
+enum_proc (const LOGFONTW *lf, const TEXTMETRICW *tm,
+ DWORD FontType, LPARAM lParam)
+{
+ int *done = (int *) lParam;
+ *done = 1;
+ return 0;
+}
+
+static void
+check_font (HANDLE hdl)
+{
+ CONSOLE_FONT_INFOEX cfi;
+ LOGFONTW lf;
+
+ cfi.cbSize = sizeof cfi;
+ if (!GetCurrentConsoleFontEx (hdl, 0, ))
+return;
+ /* Switched font? */
+ if (wcscmp (cons_facename, cfi.FaceName) == 0)
+return;
+ if (!cdc && !(cdc = GetDC (GetConsoleWindow (
+return;
+ /* Some FaceNames like DejaVu Sans Mono are sometimes returned with stray
+ trailing chars. Fix it. */
+ lf.lfCharSet = ANSI_CHARSET;
+ lf.lfPitchAndFamily = FIXED_PITCH | FF_DONTCARE;
+ wchar_t *cp = wcpcpy (lf.lfFaceName, cfi.FaceName) - 1;
+ int done = 0;
+ do
+{
+ EnumFontFamiliesExW (cdc, , enum_proc, (LPARAM) , 0);
+ if (!done && cp > lf.lfFaceName)
+ *cp-- = L'\0';
+}
+ while (!done);
+ /* Yes. Check for the best replacement char. */
+ HFONT f = CreateFontW (0, 0, 0, 0,
+cfi.FontWeight, FALSE, FALSE, FALSE,
+ANSI_CHARSET, OUT_DEFAULT_PRECIS,
+CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY,
+FIXED_PITCH | FF_DONTCARE, lf.lfFaceName);
+ if (!f)
+return;
+
+ HFONT old_f = (HFONT) SelectObject(cdc, f);
+ if (old_f)
+{
+ WORD glyph_idx[NUM_REPLACEMENT_CHARS];
+
+ if (GetGlyphIndicesW (cdc, replacement_char,
+ NUM_REPLACEMENT_CHARS, glyph_idx,
+ GGI_MARK_NONEXISTING_GLYPHS) != GDI_ERROR)
+ {
+ int i;
+
+ for (i = 0; i < NUM_REPLACEMENT_CHARS; ++i)
+ if (glyph_idx[i] != 0x)
+ break;
+ if (i == NUM_REPLACEMENT_CHARS)
+ i = 0;
+ rp_char_idx = i;
+ /* Note that we copy the original name returned by
+GetCurrentConsoleFontEx, even if it was broken.
+This allows an early return, rather than to store
+the fixed name and then having to enum font families
+all over again. */
+ wcscpy (cons_facename, cfi.FaceName);
+ }
+ SelectObject (cdc, old_f);
+}
+ DeleteObject (f);
+}
+
/* This gets called when we found an invalid input character.
- Print Unicode REPLACEMENT CHARACTER (UTF 0xfffd). */
+ Print one of the above Unicode chars as replacement char. */
inline void
fhandler_console::write_replacement_char ()
{
- static const
[newlib-cygwin] Cygwin: console: use UNICODE API throughout
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=213d8cac24ce234255179717723626ed16b33fe8
commit 213d8cac24ce234255179717723626ed16b33fe8
Author: Corinna Vinschen
Date: Wed Sep 5 13:08:33 2018 +0200
Cygwin: console: use UNICODE API throughout
Signed-off-by: Corinna Vinschen
Diff:
---
winsup/cygwin/fhandler_console.cc | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/winsup/cygwin/fhandler_console.cc
b/winsup/cygwin/fhandler_console.cc
index 9a6c9b1..b4674b8 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -759,7 +759,7 @@ dev_console::scroll_buffer (HANDLE h, int x1, int y1, int
x2, int y2, int xn, in
SMALL_RECT sr1, sr2;
CHAR_INFO fill;
COORD dest;
- fill.Char.AsciiChar = ' ';
+ fill.Char.UnicodeChar = L' ';
fill.Attributes = current_win32_attr;
fillin (h);
@@ -775,7 +775,7 @@ dev_console::scroll_buffer (HANDLE h, int x1, int y1, int
x2, int y2, int xn, in
sr1.Bottom = sr2.Bottom;
dest.X = xn >= 0 ? xn : dwWinSize.X - 1;
dest.Y = yn >= 0 ? yn : b.srWindow.Bottom;
- ScrollConsoleScreenBuffer (h, , , dest, );
+ ScrollConsoleScreenBufferW (h, , , dest, );
}
inline void
@@ -822,7 +822,7 @@ fhandler_console::open (int flags, mode_t)
set_output_handle (NULL);
/* Open the input handle as handle_ */
- h = CreateFile ("CONIN$", GENERIC_READ | GENERIC_WRITE,
+ h = CreateFileW (L"CONIN$", GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE, _none,
OPEN_EXISTING, 0, 0);
@@ -833,7 +833,7 @@ fhandler_console::open (int flags, mode_t)
}
set_io_handle (h);
- h = CreateFile ("CONOUT$", GENERIC_READ | GENERIC_WRITE,
+ h = CreateFileW (L"CONOUT$", GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE, _none,
OPEN_EXISTING, 0, 0);
@@ -1226,9 +1226,9 @@ dev_console::scroll_window (HANDLE h, int x1, int y1, int
x2, int y2)
br.Right = b.dwSize.X - 1;
br.Bottom = b.dwSize.Y - 1;
dest.X = dest.Y = 0;
- fill.Char.AsciiChar = ' ';
+ fill.Char.UnicodeChar = L' ';
fill.Attributes = current_win32_attr;
- ScrollConsoleScreenBuffer (h, , NULL, dest, );
+ ScrollConsoleScreenBufferW (h, , NULL, dest, );
/* Since we're moving the console buffer under the console window
we only have to move the console window if the user scrolled the
window upwards. The number of lines is the distance to the
RE: Segmentation fault when compiling *FIXED*
In the latest build of Windows 10, sent out on 5 Sep 2018, the gcc compiler no longer gives a segmentation error. Whew! I'm glad that's fixed. Tom L -Original Message- From: cygwin-ow...@cygwin.com On Behalf Of cygwin-digest-h...@cygwin.com Sent: Wednesday, August 29, 2018 8:35 PM To: cygwin@cygwin.com Subject: cygwin Digest 30 Aug 2018 00:35:09 - Issue 10983 cygwin Digest 30 Aug 2018 00:35:09 - Issue 10983 Topics (messages 213705 through 213711): [ANNOUNCEMENT] Updated: xorg-server-1.20.1-1 213705 by: Jon Turney Re: libmpi_cxx.dll.a missing 213706 by: Marco Atzeri Re: gecko Segmentation fault when compiling 213707 by: Marco Atzeri 213708 by: Andrey Repin 213709 by: tlake.twcny.rr.com Re: "build-essential" metapackage [WAS: FW: gecko Segmentation fault when compiling] 213710 by: cyg Simple 213711 by: Andrey Repin Administrivia: To subscribe to the digest, e-mail: cygwin-digest-subscr...@cygwin.com To unsubscribe from the digest, e-mail: cygwin-digest-unsubscr...@cygwin.com To post to the list, e-mail: cygwin@cygwin.com -- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why does -std=c++11 hide certain function calls
On 2018-09-05 13:36, John Selbie wrote: > On Wed, Sep 5, 2018 at 11:46 AM Hans-Bernhard Bröker wrote: >> Am 05.09.2018 um 07:55 schrieb John Selbie: >>> With this: g++ foo.cpp -c -std=c++11 >>> It compiles fine everywhere else, except CygWin. Output on Cygwin: >> I'm afraid that may mean everywhere else is wrong. >>> Yes, switching to -std=gnu++11 or adding -D_DEFAULT_SOURCE to the >>> command line works. >>> But I don't understand why the need to enforce these extensions to get >>> access to some of the most common unix libraries? >> Because that's what std=c++11 is meant and documented to do. It turns >> off all extensions to the standard language. And yes, that does include >> extensions to the standard libary, up to and including POSIX-specific >> content. >> For what you want to do, std=c++11 is simply the wrong setting. > But why is getaddrinfo (and its associated struct types and flag values) > considered a "language extension" and hidden via the __POSIX_VISIBILE > define when other function declarations in netdb.h (such as getservbyname) > are not? > I don't believe C++ has any formal support for networking. So it's > surprising to see one networking function hidden "because its an > extension", but the other very related functions are not. Can you elaborate > on the decision process that makes it this way? I honestly don't see how a > header file qualifies as a language extension, but instead just see it as > the interface for a pre-compiled library. > Is it because modern C++ is defined to support older POSIX functions, but > not newer ones? Where is that in the standard? > As I said before, I'm wanting to be educated on this, because it could > influence how I view the writing and building of portable code now and in > the future. But saying, "everywhere else but here is wrong" and because ", > doesn't help. Depends on how standards compliant the implementation and the developer are. Some(/all?) BSDs specify nothing, but POSIX and other standards specify feature test macros to enable access to those functions be defined for every C source module that requires them before any includes e.g. for Linux/GLIBC getaddrinfo(3): "Feature Test Macro Requirements for glibc (see feature_test_macros(7)): getaddrinfo(), freeaddrinfo(), gai_strerror(): _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _POSIX_SOURCE" so to be guaranteed access to those functions, you should define and set one of those symbols, in each source file, build command line, or makefile, which -std=gnu* (or no -std flag) does for you. For Unixy builds, just don't specify -std. Only specify -std if you want to ensure that builds will work with earlier standards, compilers, or libraries, or for -std=c* without any special language or library features, in which case you may also want to add -pedantic or more restrictive options. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin fails to utilize Unicode replacement character
On Sep 5 17:58, Corinna Vinschen wrote:
> On Sep 5 15:18, Marco Atzeri wrote:
> > Am 05.09.2018 um 13:58 schrieb Steven Penny:
> > > On Wed, 5 Sep 2018 09:55:28, Corinna Vinschen wrote:
> >
> > > Using this file:
> > >
> > > $ cat glyph.c
> > > #include
> > > #include
> > > int main()
> > > {
> > > CONSOLE_FONT_INFOEX ta;
> > > ta.cbSize = sizeof ta;
> > > GetCurrentConsoleFontEx(GetStdHandle(STD_OUTPUT_HANDLE), 0, );
> > > HDC wh = GetDC(0);
> > > SelectObject(wh,
> > > CreateFontW(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ta.FaceName));
> > > WCHAR xr[4] = {0xFFFD, 0x2592, 0x25A1, 0x01C4};
> > > WORD zu[4];
> > > GetGlyphIndicesW(wh, xr, 4, zu, 1);
> > > printf("%ls:\n", ta.FaceName);
> > > for (int q = 0; q < 4; q++) {
> > > printf(" U+%04X: %s\n",
> > > xr[q], zu[q] == 0x ? "failure" : "success");
> > > }
> > > }
> > >
> > > I get this result:
> > >
> > > DejaVu Sans Mono:
> > > U+FFFD: success
> > > U+2592: success
> > > U+25A1: success
> > > U+01C4: failure
> > >
> >
> > Strange on W10 CMD I obtain
> >
> > DejaVu Sans Mono U+FFFD: failure
> ^^^
> You see this? There's something really fishy here. I see a similar
> effect which somehow depends on arbitrary changes to the source file:
>
> - Sometimes I get "DejaVu Sans Mono" in FaceName and all works well.
> - Sometimes I get "DejaVu Sans Mono\1" or "DejaVu Sans Mono\6" and
> the subsequent GetGlyphIndicesW returns failures for many or all
> characters.
>
> I'm trying to find what's affecting this for hours, but I don't get any
> conclusive results :(
OTOH, in my testing this only occurs for DejaVu Sans Mono. I installed
Liberation Mono and Noto Mono as well and the above problem never occurs
with them. Weird. I'm about to let this slip as a font bug.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
Re: Why does -std=c++11 hide certain function calls
Thanks for the response. But why is getaddrinfo (and its associated struct types and flag values) considered a "language extension" and hidden via the __POSIX_VISIBILE define when other function declarations in netdb.h (such as getservbyname) are not? I don't believe C++ has any formal support for networking. So it's surprising to see one networking function hidden "because its an extension", but the other very related functions are not. Can you elaborate on the decision process that makes it this way? I honestly don't see how a header file qualifies as a language extension, but instead just see it as the interface for a pre-compiled library. Is it because modern C++ is defined to support older POSIX functions, but not newer ones? Where is that in the standard? As I said before, I'm wanting to be educated on this, because it could influence how I view the writing and building of portable code now and in the future. But saying, "everywhere else but here is wrong" and because ", doesn't help. jrs On Wed, Sep 5, 2018 at 11:46 AM Hans-Bernhard Bröker wrote: > Am 05.09.2018 um 07:55 schrieb John Selbie: > > > With this: g++ foo.cpp -c -std=c++11 > > It compiles fine everywhere else, except CygWin. Output on Cygwin: > > I'm afraid that may mean everywhere else is wrong. > > > Yes, switching to -std=gnu++11 or adding -D_DEFAULT_SOURCE to the > command > > line line works. > > > > But I don't understand why the need to enforce these extensions to get > > access to some of the most common unix libraries? > > Because that's what std=c++11 is meant and documented to do. It turns > off all extensions to the standard language. And yes, that does include > extensions to the standard libary, up to and including POSIX-specific > content. > > For what you want to do, std=c++11 is simply the wrong setting. > > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Why does -std=c++11 hide certain function calls
Am 05.09.2018 um 07:55 schrieb John Selbie: With this: g++ foo.cpp -c -std=c++11 It compiles fine everywhere else, except CygWin. Output on Cygwin: I'm afraid that may mean everywhere else is wrong. Yes, switching to -std=gnu++11 or adding -D_DEFAULT_SOURCE to the command line line works. But I don't understand why the need to enforce these extensions to get access to some of the most common unix libraries? Because that's what std=c++11 is meant and documented to do. It turns off all extensions to the standard language. And yes, that does include extensions to the standard libary, up to and including POSIX-specific content. For what you want to do, std=c++11 is simply the wrong setting. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin fails to utilize Unicode replacement character
On Sep 5 15:18, Marco Atzeri wrote:
> Am 05.09.2018 um 13:58 schrieb Steven Penny:
> > On Wed, 5 Sep 2018 09:55:28, Corinna Vinschen wrote:
>
> > Using this file:
> >
> > $ cat glyph.c
> > #include
> > #include
> > int main()
> > {
> > CONSOLE_FONT_INFOEX ta;
> > ta.cbSize = sizeof ta;
> > GetCurrentConsoleFontEx(GetStdHandle(STD_OUTPUT_HANDLE), 0, );
> > HDC wh = GetDC(0);
> > SelectObject(wh,
> > CreateFontW(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ta.FaceName));
> > WCHAR xr[4] = {0xFFFD, 0x2592, 0x25A1, 0x01C4};
> > WORD zu[4];
> > GetGlyphIndicesW(wh, xr, 4, zu, 1);
> > printf("%ls:\n", ta.FaceName);
> > for (int q = 0; q < 4; q++) {
> > printf(" U+%04X: %s\n",
> > xr[q], zu[q] == 0x ? "failure" : "success");
> > }
> > }
> >
> > I get this result:
> >
> > DejaVu Sans Mono:
> > U+FFFD: success
> > U+2592: success
> > U+25A1: success
> > U+01C4: failure
> >
>
> Strange on W10 CMD I obtain
>
> DejaVu Sans Mono U+FFFD: failure
^^^
You see this? There's something really fishy here. I see a similar
effect which somehow depends on arbitrary changes to the source file:
- Sometimes I get "DejaVu Sans Mono" in FaceName and all works well.
- Sometimes I get "DejaVu Sans Mono\1" or "DejaVu Sans Mono\6" and
the subsequent GetGlyphIndicesW returns failures for many or all
characters.
I'm trying to find what's affecting this for hours, but I don't get any
conclusive results :(
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
Re: Cygwin fails to utilize Unicode replacement character
Greetings, Marco Atzeri! > Strange on W10 CMD I obtain > DejaVu Sans Mono >U+FFFD: failure >U+2592: failure >U+25A1: failure >U+01C4: failure > Consolas: >U+FFFD: failure >U+2592: success >U+25A1: success >U+01C4: success > May be original Windows "DejaVu Sans Mono" is incomplete ? Win7 64, Terminal: U+FFFD: failure U+2592: failure U+25A1: failure U+01C4: failure Consolas: U+FFFD: failure U+2592: success U+25A1: success U+01C4: success Lucida Console: U+FFFD: failure U+2592: success U+25A1: failure U+01C4: failure DejaVu Sans Mono: U+FFFD: success U+2592: success U+25A1: success U+01C4: failure DejaVu Sans Mono 2.33 as released as part of official 2.37 release. -- With best regards, Andrey Repin Wednesday, September 5, 2018 17:57:15 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: openmpi-3.1.2-1
Version 3.1.2-1 of packages libopenmpi-devel libopenmpi40 libopenmpifh40 libopenmpiusef08_40 libopenmpiusetkr40 openmpi are available in the Cygwin distribution: CHANGES Latest upstream release. https://www.mail-archive.com/announce@lists.open-mpi.org/msg00114.html Full upstream changes: https://github.com/open-mpi/ompi/blob/master/NEWS CYGWIN CHANGES Removed the C++ compiler invocation as upstream depracated the C++ interface DESCRIPTION Open MPI : A High Performance Message Passing Library The Open MPI Project is an open source MPI-3 implementation that is developed and maintained by a consortium of academic, research, and industry partners CYGWIN NOTES openmpi requires a running cygserver HOMEPAGE http://www.open-mpi.org/ Marco Atzeri If you have questions or comments, please send them to the --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Updated: openmpi-3.1.2-1
Version 3.1.2-1 of packages libopenmpi-devel libopenmpi40 libopenmpifh40 libopenmpiusef08_40 libopenmpiusetkr40 openmpi are available in the Cygwin distribution: CHANGES Latest upstream release. https://www.mail-archive.com/announce@lists.open-mpi.org/msg00114.html Full upstream changes: https://github.com/open-mpi/ompi/blob/master/NEWS CYGWIN CHANGES Removed the C++ compiler invocation as upstream depracated the C++ interface DESCRIPTION Open MPI : A High Performance Message Passing Library The Open MPI Project is an open source MPI-3 implementation that is developed and maintained by a consortium of academic, research, and industry partners CYGWIN NOTES openmpi requires a running cygserver HOMEPAGE http://www.open-mpi.org/ Marco Atzeri If you have questions or comments, please send them to the --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus
Re: Tab completion adding spurious escape characters
On 09/04/2018 10:46 PM, Steven Penny wrote:
If you create this file:
touch -- \''-#%.!$&(),;@[]^`{}=_~+9zZ'
Then enter "touch", "Tab", "Tab", you get this:
touch \'-#%.\!\$\&\(\)\,\;\@\[\]\^\`\{\}\=_~+9zZ
So the shell is saying that these characters need to be escaped:
' ! $ & ( ) , ; @ [ ] ^ ` { } =
but they dont, not all of them:
$ (set -x; true \' \! \$ \& \( \) \, \; \@ \[ \] \^ \` \{ \} \=)
+ true \' '!' '$' '&' '(' ')' , ';' @ '[' ']' '^' '`' '{' '}' =
Notice carefully that the shell removes escaping for these:
, @ =
but tab completion is adding it. Is this an issue of Readline or Cygwin?
Not cygwin specific, because you get the same behavior on Linux.
Therefore, it is is an upstream readline/bash decision on what to escape
during tab completion. (And since tab completion is a readline feature,
and readline is implemented by the author of bash, there really is no
reason to assume it would be an issue specific to Cygwin).
Also, whether or not those characters are escaped does not generally
change the actual command line you are executing, and it is a lot less
code to just blindly escape things than to figure out a minimal output,
so I see no reason to bother changing things. (Actually, there ARE
cases where = and \= behave differently, but not in what you typed. For
a demonstration:
$ echo 'echo hi' > ./a=b
$ chmod +x a=b
$ a=c
$ echo $a
c
$ (PATH=:$PATH; a\=b; echo $a)
hi
c
$ (PATH=:$PATH; a=b; echo $a)
b
As for , and @, they are never special to the shell, but as I argued
above, it's easier to write tab completion code that doesn't have to
special case things than to worry about what is or is not special)
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin fails to utilize Unicode replacement character
Greetings, Houder! >> > a character that DejaVu Sans Mono actually doesnt have is: >> >> > U+01C4 LATIN CAPITAL LETTER DZ WITH CARON >> >> > Using this file: >> >> How to compile it? >> Simple "gcc glyph.c" fails with >> >> /tmp/ccSCYXAP.o:glyph.c:(.text+0xbd): undefined reference to >> `__imp_CreateFontW' >> /tmp/ccSCYXAP.o:glyph.c:(.text+0xbd): relocation truncated to fit: >> R_X86_64_PC32 against undefined symbol `__imp_CreateFontW' >> /tmp/ccSCYXAP.o:glyph.c:(.text+0xd0): undefined reference to >> `__imp_SelectObject' >> /tmp/ccSCYXAP.o:glyph.c:(.text+0xd0): relocation truncated to fit: >> R_X86_64_PC32 against undefined symbol `__imp_SelectObject' >> /tmp/ccSCYXAP.o:glyph.c:(.text+0x111): undefined reference to >> `__imp_GetGlyphIndicesW' >> /tmp/ccSCYXAP.o:glyph.c:(.text+0x111): relocation truncated to fit: >> R_X86_64_PC32 against undefined symbol `__imp_GetGlyphIndicesW' >> collect2: error: ld returned 1 exit status > 64-@@ gcc -o glyph glyph.c -lgdi32 Thanks, that's better. Somewhat. -- With best regards, Andrey Repin Wednesday, September 5, 2018 17:52:46 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
ghostscript 9.24-1
The following packages have been uploaded to the Cygwin distribution: * ghostscript-9.24-1 * libgs9-9.24-1 * libgs-devel-9.24-1 GNU Ghostscript is a PostScript interpreter capable of converting PS files into a number of printer output formats. Ghostscript can also render PS files into a number of graphics file formats. This is an update to the latest upstream release. It is a bugfix release, primarily for security issues. Ken Brown Cygwin's Ghostscript maintainer
[ANNOUNCEMENT] ghostscript 9.24-1
The following packages have been uploaded to the Cygwin distribution: * ghostscript-9.24-1 * libgs9-9.24-1 * libgs-devel-9.24-1 GNU Ghostscript is a PostScript interpreter capable of converting PS files into a number of printer output formats. Ghostscript can also render PS files into a number of graphics file formats. This is an update to the latest upstream release. It is a bugfix release, primarily for security issues. Ken Brown Cygwin's Ghostscript maintainer -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin fails to utilize Unicode replacement character
On Wed, 5 Sep 2018 16:31:33, Andrey Repin wrote: > Greetings, Steven Penny! > > > a character that DejaVu Sans Mono actually doesnt have is: > > > U+01C4 LATIN CAPITAL LETTER DZ WITH CARON > > > Using this file: > > How to compile it? > Simple "gcc glyph.c" fails with > > /tmp/ccSCYXAP.o:glyph.c:(.text+0xbd): undefined reference to > `__imp_CreateFontW' > /tmp/ccSCYXAP.o:glyph.c:(.text+0xbd): relocation truncated to fit: > R_X86_64_PC32 against undefined symbol `__imp_CreateFontW' > /tmp/ccSCYXAP.o:glyph.c:(.text+0xd0): undefined reference to > `__imp_SelectObject' > /tmp/ccSCYXAP.o:glyph.c:(.text+0xd0): relocation truncated to fit: > R_X86_64_PC32 against undefined symbol `__imp_SelectObject' > /tmp/ccSCYXAP.o:glyph.c:(.text+0x111): undefined reference to > `__imp_GetGlyphIndicesW' > /tmp/ccSCYXAP.o:glyph.c:(.text+0x111): relocation truncated to fit: > R_X86_64_PC32 against undefined symbol `__imp_GetGlyphIndicesW' > collect2: error: ld returned 1 exit status 64-@@ gcc -o glyph glyph.c -lgdi32 ? Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin fails to utilize Unicode replacement character
Greetings, Steven Penny!
> a character that DejaVu Sans Mono actually doesnt have is:
> U+01C4 LATIN CAPITAL LETTER DZ WITH CARON
> Using this file:
How to compile it?
Simple "gcc glyph.c" fails with
/tmp/ccSCYXAP.o:glyph.c:(.text+0xbd): undefined reference to `__imp_CreateFontW'
/tmp/ccSCYXAP.o:glyph.c:(.text+0xbd): relocation truncated to fit:
R_X86_64_PC32 against undefined symbol `__imp_CreateFontW'
/tmp/ccSCYXAP.o:glyph.c:(.text+0xd0): undefined reference to
`__imp_SelectObject'
/tmp/ccSCYXAP.o:glyph.c:(.text+0xd0): relocation truncated to fit:
R_X86_64_PC32 against undefined symbol `__imp_SelectObject'
/tmp/ccSCYXAP.o:glyph.c:(.text+0x111): undefined reference to
`__imp_GetGlyphIndicesW'
/tmp/ccSCYXAP.o:glyph.c:(.text+0x111): relocation truncated to fit:
R_X86_64_PC32 against undefined symbol `__imp_GetGlyphIndicesW'
collect2: error: ld returned 1 exit status
Though I see the header files present at their appropriate places.
> $ cat glyph.c
> #include
> #include
> int main()
> {
> CONSOLE_FONT_INFOEX ta;
> ta.cbSize = sizeof ta;
> GetCurrentConsoleFontEx(GetStdHandle(STD_OUTPUT_HANDLE), 0, );
> HDC wh = GetDC(0);
> SelectObject(wh,
> CreateFontW(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ta.FaceName));
> WCHAR xr[4] = {0xFFFD, 0x2592, 0x25A1, 0x01C4};
> WORD zu[4];
> GetGlyphIndicesW(wh, xr, 4, zu, 1);
> printf("%ls:\n", ta.FaceName);
> for (int q = 0; q < 4; q++) {
> printf(" U+%04X: %s\n",
> xr[q], zu[q] == 0x ? "failure" : "success");
> }
> }
> I get this result:
> DejaVu Sans Mono:
> U+FFFD: success
> U+2592: success
> U+25A1: success
> U+01C4: failure
--
With best regards,
Andrey Repin
Wednesday, September 5, 2018 16:30:20
Sorry for my terrible english...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin fails to utilize Unicode replacement character
Am 05.09.2018 um 13:58 schrieb Steven Penny:
On Wed, 5 Sep 2018 09:55:28, Corinna Vinschen wrote:
Using this file:
$ cat glyph.c
#include
#include
int main()
{
CONSOLE_FONT_INFOEX ta;
ta.cbSize = sizeof ta;
GetCurrentConsoleFontEx(GetStdHandle(STD_OUTPUT_HANDLE), 0, );
HDC wh = GetDC(0);
SelectObject(wh,
CreateFontW(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ta.FaceName));
WCHAR xr[4] = {0xFFFD, 0x2592, 0x25A1, 0x01C4};
WORD zu[4];
GetGlyphIndicesW(wh, xr, 4, zu, 1);
printf("%ls:\n", ta.FaceName);
for (int q = 0; q < 4; q++) {
printf(" U+%04X: %s\n",
xr[q], zu[q] == 0x ? "failure" : "success");
}
}
I get this result:
DejaVu Sans Mono:
U+FFFD: success
U+2592: success
U+25A1: success
U+01C4: failure
Strange on W10 CMD I obtain
DejaVu Sans Mono U+FFFD: failure
U+2592: failure
U+25A1: failure
U+01C4: failure
Consolas:
U+FFFD: failure
U+2592: success
U+25A1: success
U+01C4: success
May be original Windows "DejaVu Sans Mono" is incomplete ?
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin fails to utilize Unicode replacement character
On Wed, 5 Sep 2018 09:55:28, Corinna Vinschen wrote:
I added DejaVu Sans Mono per the above and to my surprise I see this:
$ cat alfa.txt
=EF=BF=BD
So it looks like Deja Vu has a 0xfffd char. However, GetGlyphIndicesW
claims otherwise:
a character that DejaVu Sans Mono actually doesnt have is:
U+01C4 LATIN CAPITAL LETTER DZ WITH CARON
Using this file:
$ cat glyph.c
#include
#include
int main()
{
CONSOLE_FONT_INFOEX ta;
ta.cbSize = sizeof ta;
GetCurrentConsoleFontEx(GetStdHandle(STD_OUTPUT_HANDLE), 0, );
HDC wh = GetDC(0);
SelectObject(wh,
CreateFontW(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ta.FaceName));
WCHAR xr[4] = {0xFFFD, 0x2592, 0x25A1, 0x01C4};
WORD zu[4];
GetGlyphIndicesW(wh, xr, 4, zu, 1);
printf("%ls:\n", ta.FaceName);
for (int q = 0; q < 4; q++) {
printf(" U+%04X: %s\n",
xr[q], zu[q] == 0x ? "failure" : "success");
}
}
I get this result:
DejaVu Sans Mono:
U+FFFD: success
U+2592: success
U+25A1: success
U+01C4: failure
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: handling invalid user/groups (was incompat in cygwin choice of using '+' as domain and user separator.)
Greetings, L A Walsh! > p.s. -- some "FYI" stuff about your email: > when i respond to one of your emails, I get two (2) > "To:" entries -- both to cygwin@cygwin.com. > I think it might be because the emails from you contain > two 'Mail-Followup-To:' lines -- see below**. They are added by list software. Your email client is expected to sort it out and only include unique addresses. Even if not, the first MTA you submit your message to should do that. > Also, I don't get your message included in a response > (because it is in a separate attachment. Is that intentional? No, it's your weird mail agent failing to parse a signed email. -- With best regards, Andrey Repin Wednesday, September 5, 2018 14:26:34 Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: Cygwin 2.11.1-1
Hi folks, I uploaded a new Cygwin release 2.11.1-1. This is a bugfix release. === Bug Fixes - - Fix ".." handling in Win32 path normalization, introduced in 2.11.0. Addresses: https://cygwin.com/ml/cygwin/2018-09/msg0.html === Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Updated: Cygwin 2.11.1-1
Hi folks, I uploaded a new Cygwin release 2.11.1-1. This is a bugfix release. === Bug Fixes - - Fix ".." handling in Win32 path normalization, introduced in 2.11.0. Addresses: https://cygwin.com/ml/cygwin/2018-09/msg0.html === Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: Cygwin fails to utilize Unicode replacement character
Am 05.09.2018 um 09:55 schrieb Corinna Vinschen:
On Sep 4 04:40, Steven Penny wrote:
On Tue, 4 Sep 2018 11:00:00, Corinna Vinschen wrote:
Whereever you get DejaVu Sans Mono from.
Cygwin provides it via the "dejavu-fonts" package, or you can get it here:
http://dejavu-fonts.github.io
My W10 console only allows to specify a handful of fonts, Consolas, Courier
New, Lucida, MS Gothic, NSimSun, Raster Fonts, SimSun-ExtB.
You can add DejaVu or others like this:
http://superuser.com/questions/390933/add-font-cmd-window-choices/956818
I added DejaVu Sans Mono per the above and to my surprise I see this:
$ cat alfa.txt
�
So it looks like Deja Vu has a 0xfffd char. However, GetGlyphIndicesW
claims otherwise:
static const wchar_t replacement_char[3] =
{
0xfffd, /* REPLACEMENT CHARACTER */
0x25a1, /* WHITE SQUARE */
0x2592 /* MEDIUM SHADE */
};
WORD gi[3] = { 0, 0, 0 };
[...]
GetGlyphIndicesW (cdc, replacement_char, 3, gi, GGI_MARK_NONEXISTING_GLYPHS);
printf ("gi = %u %u %u\n", gi[0], gi[1], gi[2]);
This prints:
gi = 65535 401 372
That means, the notdef glyph for DejaVu looks like 0xfffd, but isn't, right?
I guess it means that (or something subtle related to font-fallback
although we previously concluded the console wouldn't support it...).
My vote remains for going back to MEDIUM SHADE, for 2.11.2 then...,
unless we find a working detection function.
Thomas
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin fails to utilize Unicode replacement character
On Sep 4 14:40, Brian Inglis wrote: > On 2018-09-04 12:20, Steven Penny wrote: > > On Tue, 4 Sep 2018 16:18:21, Thomas Wolff wrote: > >> My vote is against the patch because the nodef glyph will often be just > >> blank > >> space which is certainly worse than ▒. > > Not according to the sample below: you would have to know that medium shade > means unavailable. > > >> If conhost does not provide a reasonable way to enquire 0xFFFD availability > >> it's conhost's fault, not cygwin's so why should cygwin implement a bad > >> compromise. If conhost ever improves, cygwin can adapt. > > This is some dangerous commentary. I would like to counter it now with some > > actual research. Using BabelMap: > > http://babelstone.co.uk/Software/BabelMap.html > > You can do "Fonts", "Font Coverage" and you will get this result with code > > point > > FFFD: > > yes: DejaVu Sans Mono > > no: > > - Consolas > > - Courier New > > - Lucida Console > > - MS Gothic > > - NSimSun > > - SimSun-ExtB > > This is concerning true, but we can then review the ".notdef glyph" for the > > problem fonts. As this glyph is not an actual character, i cant paste it > > here, > > but i will describe them below: > > empty rectangle: > > - Courier New > > - Lucida Console > > - MS Gothic > > - SimSun-ExtB > > rectangle with a question mark inside: Consolas > > These are both recommended .notdef glyphs. > > > none: NSimSun > > Valid OTF and TTF fonts must have a glyph with index entry 0 used for .notdef. Discussion closed for 2.11.1. I'm going to release it as is, with 0xfffd as replacement char. A better/more complex solution will have to go into the next release. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
[newlib-cygwin] Created tag cygwin-2_11_1-release
The signed tag 'cygwin-2_11_1-release' was created pointing to: 86c31ae... math_config.h: Fix signed overflow warning for 16-bit targe Tagger: Corinna Vinschen Date: Wed Sep 5 10:05:52 2018 +0200 Cygwin 2.11.1 Release
Re: handling invalid user/groups (was incompat in cygwin choice of using '+' as domain and user separator.)
On Sep 4 13:08, L A Walsh wrote: > On 8/27/2018 10:26 AM, Corinna Vinschen wrote: > > On 8/27/2018 3:50 AM, Corinna Vinschen wrote: > > The only sane way to handle unknown SIDs in file ACLs is to ignore them > > entirely. The result will be that you never see them in getfacl, nor > > will they be stored by tar or rsync. They are just not there from the > > Cygwin perspective. > --- > Sounds fine to me... > > > I created a patch, uploaded developer snapshots to > > https://cygwin.com/snapshots/ and released a new Cygwin test > > release 2.11.0-0.4 with this change. Please giver any of > > them a try. > > does the latest cygwin also have this patch No, I deliberately removed it from the released version to tease you. > p.s. -- some "FYI" stuff about your email: >when i respond to one of your emails, I get two (2)"To:" > entries -- both to cygwin@cygwin.com. > I think it might be because the emails from you contain > two 'Mail-Followup-To:' lines -- see below**. I only add a reply-to. I have no idea where the followup to's are generated. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: Cygwin fails to utilize Unicode replacement character
On Sep 4 04:40, Steven Penny wrote:
> On Tue, 4 Sep 2018 11:00:00, Corinna Vinschen wrote:
> > Whereever you get DejaVu Sans Mono from.
>
> Cygwin provides it via the "dejavu-fonts" package, or you can get it here:
>
> http://dejavu-fonts.github.io
>
> > My W10 console only allows to specify a handful of fonts, Consolas, Courier
> > New, Lucida, MS Gothic, NSimSun, Raster Fonts, SimSun-ExtB.
>
> You can add DejaVu or others like this:
>
> http://superuser.com/questions/390933/add-font-cmd-window-choices/956818
I added DejaVu Sans Mono per the above and to my surprise I see this:
$ cat alfa.txt
�
So it looks like Deja Vu has a 0xfffd char. However, GetGlyphIndicesW
claims otherwise:
static const wchar_t replacement_char[3] =
{
0xfffd, /* REPLACEMENT CHARACTER */
0x25a1, /* WHITE SQUARE */
0x2592 /* MEDIUM SHADE */
};
WORD gi[3] = { 0, 0, 0 };
[...]
GetGlyphIndicesW (cdc, replacement_char, 3, gi, GGI_MARK_NONEXISTING_GLYPHS);
printf ("gi = %u %u %u\n", gi[0], gi[1], gi[2]);
This prints:
gi = 65535 401 372
That means, the notdef glyph for DejaVu looks like 0xfffd, but isn't,
right?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
