Re: How to run xinit without first entering a cygwin terminal
By the way, the error that popped up when running startx from the windows command line was something like this: "Failed to connect to socket /tmp/dbus-XsPeRupEi : connection refused" and "environment variable $XDG_CONFIG_DIRS isn't properly configured" On 30 October 2015 at 08:40, Xuehan Xu wrote: > Thanks for your reply:-) > > I followed your advice, now it seems that rdesktop is running, but the > window that xinit showed was just plain black. rdesktop is supposed to > be a remote desktop client that runs on linux and connect to a windows > remote desktop. When I use the command "/usr/bin/xinit.exe > ./rdesktop/rdesktop.exe -f 192.168.1.79" in a cygwin terminal, it can > show the desktop of 192.168.1.79. > > Could this be due to the same reason that startx can't show the > cygwin desktop? What should I do? Thanks;-) > > On 29 October 2015 at 21:23, Jon Turney wrote: >> On 29/10/2015 06:25, Xuehan Xu wrote: >>> >>> Hi, everyone >>> >>> I'm trying to run xinit.exe to start a GUI program in a windows cmd >>> prompt. The command I run: >>> >>> "c:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/xinit.exe >>> /home/Administrator/rdesktop.exe -f 192.168.1.79 >>> >>> But, it seems that rdesktop.exe isn't running, the window was just >>> showing a terminal prompt. >> >> >> Using the command lines from the start menu items created for the xinit >> package as a template (see [1]), I think you need something like: >> >> c:\cygwin\bin\run.exe -quote /usr/bin/bash.exe -l -c "/usr/bin/xinit.exe >> /home/Administrator/rdesktop.exe -f 192.168.1.79" >> >> The command string being given to bash -c needs quoting, otherwise >> subsequent words are assumed to be parameters to that command. >> >> run needs to be given the -quote option to protect those quotes. >> >> [1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-command-line-args >> >> -- >> Jon TURNEY >> Volunteer Cygwin/X X Server 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: How to run xinit without first entering a cygwin terminal
Thanks for your reply:-) I followed your advice, now it seems that rdesktop is running, but the window that xinit showed was just plain black. rdesktop is supposed to be a remote desktop client that runs on linux and connect to a windows remote desktop. When I use the command "/usr/bin/xinit.exe ./rdesktop/rdesktop.exe -f 192.168.1.79" in a cygwin terminal, it can show the desktop of 192.168.1.79. Could this be due to the same reason that startx can't show the cygwin desktop? What should I do? Thanks;-) On 29 October 2015 at 21:23, Jon Turney wrote: > On 29/10/2015 06:25, Xuehan Xu wrote: >> >> Hi, everyone >> >> I'm trying to run xinit.exe to start a GUI program in a windows cmd >> prompt. The command I run: >> >> "c:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/xinit.exe >> /home/Administrator/rdesktop.exe -f 192.168.1.79 >> >> But, it seems that rdesktop.exe isn't running, the window was just >> showing a terminal prompt. > > > Using the command lines from the start menu items created for the xinit > package as a template (see [1]), I think you need something like: > > c:\cygwin\bin\run.exe -quote /usr/bin/bash.exe -l -c "/usr/bin/xinit.exe > /home/Administrator/rdesktop.exe -f 192.168.1.79" > > The command string being given to bash -c needs quoting, otherwise > subsequent words are assumed to be parameters to that command. > > run needs to be given the -quote option to protect those quotes. > > [1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-command-line-args > > -- > Jon TURNEY > Volunteer Cygwin/X X Server 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: Bug in collation functions?
On 10/29/2015 5:49 PM, Ken Brown wrote: On 10/29/2015 2:42 PM, Ken Brown wrote: On 10/29/2015 12:51 PM, Eric Blake wrote: On 10/29/2015 10:13 AM, Ken Brown wrote: Never mind. My test case was flawed, because it didn't check for the possibility that wcscoll might return 0. Here's a revised definition of the "compare" function: void compare (const wchar_t *a, const wchar_t *b, const char *loc) { setlocale (LC_COLLATE, loc); int res = wcscoll (a, b); char c = res < 0 ? '<' : res > 0 ? '>' : '='; printf ("\"%ls\" %c \"%ls\" in %s locale\n", a, c, b, loc); } With this change (and the use of NORM_IGNORESYMBOLS) the test returns the following on Cygwin: $ ./wcscoll_test "11" > "1.1" in POSIX locale "11" = "1.1" in en_US.UTF-8 locale "11" > "1 2" in POSIX locale "11" < "1 2" in en_US.UTF-8 locale It still differs from Linux, but it's good enough to make the emacs test pass. Moreover, this behavior actually seems more reasonable to me than the Linux behavior. After all, if you're ignoring punctuation, how can you decide which of "11" or "1.1" comes first? Careful. POSIX is proposing some wording that say that normal locales should always implement a fallback of last resort (and that locales that do not do so should have a special name including '@', to make it obvious). It is not standardized yet, but worth thinking about. http://austingroupbugs.net/view.php?id=938 http://austingroupbugs.net/view.php?id=963 The intent of that wording is that if ignoring punctuation could cause two strings to otherwise compare equal, the fallback of a total ordering on all characters means that the final result of strcoll() will not be 0 unless the two strings are identical. In that case, I think Cygwin should start by using NORM_IGNORESYMBOLS in non-POSIX locales, with the goal of eventually moving toward emulating glibc. I don't know what fallback glibc uses or how hard it would be to implement this on Cygwin. I withdraw this suggestion. I took a look at the glibc code, and I don't see any reasonable way for Cygwin to emulate it precisely. On the other hand, I have an idea for a simple fallback. I'll play with it a little and then submit a patch. The fallback I had in mind is to return the shorter string if they have different lengths and otherwise to revert to wcscmp. Using this, both Cygwin and Linux give the following comparisons: "11" > "1.1" in POSIX locale "11" < "1.1" in en_US.UTF-8 locale "11" > "1 2" in POSIX locale "11" < "1.2" in en_US.UTF-8 locale "1 1" < "1.1" in POSIX locale "1 1" < "1.1" in en_US.UTF-8 locale If this seems reasonable, I'll test it more extensively and then submit a patch. Ken P.S. In case others want to test this in different locales, here's the patch so far, just for wcscoll: diff --git a/winsup/cygwin/nlsfuncs.cc b/winsup/cygwin/nlsfuncs.cc index f7031f9..c33aa24 100644 --- a/winsup/cygwin/nlsfuncs.cc +++ b/winsup/cygwin/nlsfuncs.cc @@ -1156,10 +1156,15 @@ wcscoll (const wchar_t *__restrict ws1, const wchar_t *__restrict ws2) if (!collate_lcid) return wcscmp (ws1, ws2); - ret = CompareStringW (collate_lcid, 0, ws1, -1, ws2, -1); + ret = CompareStringW (collate_lcid, NORM_IGNORESYMBOLS, ws1, -1, ws2, -1); if (!ret) set_errno (EINVAL); - return ret - CSTR_EQUAL; + ret -= CSTR_EQUAL; + if (!ret) +ret = wcslen (ws1) - wcslen (ws2); + if (!ret) +ret = wcscmp (ws1, ws2); + return ret; } extern "C" int -- 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
64 bit has different dependencies somehow?
As a note, when installing these packages: setup-x86.exe ^ --quiet-mode ^ --no-admin ^ --no-startmenu ^ --no-shortcuts ^ --no-desktop ^ --site http://mirrors.xmission.com/cygwin/ ^ --root %cd% ^ --packages ^ ed,curl,wget,subversion,texinfo,gcc-g++,bison,flex,cvs,yasm,automake,libtool,autoconf,gcc-core,cmake,git,make,pkg-config,zlib1g-dev,mercurial,unzip,pax,ncurses,patch and setup-x86_64.exe ^ --quiet-mode ^ --no-admin ^ --no-startmenu ^ --no-shortcuts ^ --no-desktop ^ --site http://mirrors.xmission.com/cygwin/ ^ --root %cd% ^ --packages ^ ed,curl,wget,subversion,texinfo,gcc-g++,bison,flex,cvs,yasm,automake,libtool,autoconf,gcc-core,cmake,git,make,pkg-config,zlib1g-dev,mercurial,unzip,pax,ncurses,patch for some reason with the 32 bit install, I get "libintl.a" installed: Directory of C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffmpeg_local_builds.good2\cygwin_local_install\lib 09/20/2015 02:02 PM 205,162 libintl.a 09/20/2015 02:02 PM39,098 libintl.dll.a 09/20/2015 02:02 PM 899 libintl.la But not the same libs for the 64 bit install. Just calling it out in case it's unexpected Cheers! -roger- -- 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: setup.exe with packages specified downloads multiple versions [?]
On 10/29/15, Marco Atzeri wrote: > > > On 29/10/2015 20:53, Roger Pack wrote: >> As a note, running this: >> >> >> setup-x86.exe ^ >> --quiet-mode ^ >> --no-admin ^ >> --no-startmenu ^ >> --no-shortcuts ^ >> --no-desktop ^ >> --site http://mirrors.xmission.com/cygwin/ ^ >> --root %cd% ^ >> --packages ^ >> ed,curl,wget,subversion,texinfo,gcc-g++,bison,flex,cvs,yasm,automake,libtool,autoconf,gcc-core,cmake,git,make,pkg-config,zlib1g-dev,mercurial,unzip,pax,ncurses,patch >> >> downloads seemingly lots of versions of particular packages [?] (note >> the duplicates of autoconf and automake, various versions: >> > [cut] >> >> Not sure if that's expected or not. >> Cheers! >> -roger- > > Setup is correct. > Autoconf and automake are wrapper managing > alternative version of the same package. > If you looks on setup.ini content: > > @ autoconf > sdesc: "Wrapper scripts for autoconf commands" > ldesc: "Wrapper scripts for autoconf commands" > category: Devel > requires: bash sed autoconf2.1 autoconf2.5 cygwin > > @ automake > sdesc: "Wrapper scripts for automake and aclocal" > ldesc: "Wrapper scripts for automake and aclocal" > category: Devel > requires: bash gawk automake1.4 automake1.5 automake1.6 automake1.7 > automake1.8 automake1.9 automake1.10 automake1.11 automake1.12 > automake1.13 automake1.14 automake1.15 cygwin OK thanks for the clarification. -roger- -- 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: Bug in collation functions?
On 10/29/2015 2:42 PM, Ken Brown wrote: On 10/29/2015 12:51 PM, Eric Blake wrote: On 10/29/2015 10:13 AM, Ken Brown wrote: Never mind. My test case was flawed, because it didn't check for the possibility that wcscoll might return 0. Here's a revised definition of the "compare" function: void compare (const wchar_t *a, const wchar_t *b, const char *loc) { setlocale (LC_COLLATE, loc); int res = wcscoll (a, b); char c = res < 0 ? '<' : res > 0 ? '>' : '='; printf ("\"%ls\" %c \"%ls\" in %s locale\n", a, c, b, loc); } With this change (and the use of NORM_IGNORESYMBOLS) the test returns the following on Cygwin: $ ./wcscoll_test "11" > "1.1" in POSIX locale "11" = "1.1" in en_US.UTF-8 locale "11" > "1 2" in POSIX locale "11" < "1 2" in en_US.UTF-8 locale It still differs from Linux, but it's good enough to make the emacs test pass. Moreover, this behavior actually seems more reasonable to me than the Linux behavior. After all, if you're ignoring punctuation, how can you decide which of "11" or "1.1" comes first? Careful. POSIX is proposing some wording that say that normal locales should always implement a fallback of last resort (and that locales that do not do so should have a special name including '@', to make it obvious). It is not standardized yet, but worth thinking about. http://austingroupbugs.net/view.php?id=938 http://austingroupbugs.net/view.php?id=963 The intent of that wording is that if ignoring punctuation could cause two strings to otherwise compare equal, the fallback of a total ordering on all characters means that the final result of strcoll() will not be 0 unless the two strings are identical. In that case, I think Cygwin should start by using NORM_IGNORESYMBOLS in non-POSIX locales, with the goal of eventually moving toward emulating glibc. I don't know what fallback glibc uses or how hard it would be to implement this on Cygwin. I withdraw this suggestion. I took a look at the glibc code, and I don't see any reasonable way for Cygwin to emulate it precisely. On the other hand, I have an idea for a simple fallback. I'll play with it a little and then submit a patch. Ken -- 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: setup.exe with packages specified downloads multiple versions [?]
On 29/10/2015 20:53, Roger Pack wrote: As a note, running this: setup-x86.exe ^ --quiet-mode ^ --no-admin ^ --no-startmenu ^ --no-shortcuts ^ --no-desktop ^ --site http://mirrors.xmission.com/cygwin/ ^ --root %cd% ^ --packages ^ ed,curl,wget,subversion,texinfo,gcc-g++,bison,flex,cvs,yasm,automake,libtool,autoconf,gcc-core,cmake,git,make,pkg-config,zlib1g-dev,mercurial,unzip,pax,ncurses,patch downloads seemingly lots of versions of particular packages [?] (note the duplicates of autoconf and automake, various versions: [cut] Not sure if that's expected or not. Cheers! -roger- Setup is correct. Autoconf and automake are wrapper managing alternative version of the same package. If you looks on setup.ini content: @ autoconf sdesc: "Wrapper scripts for autoconf commands" ldesc: "Wrapper scripts for autoconf commands" category: Devel requires: bash sed autoconf2.1 autoconf2.5 cygwin @ automake sdesc: "Wrapper scripts for automake and aclocal" ldesc: "Wrapper scripts for automake and aclocal" category: Devel requires: bash gawk automake1.4 automake1.5 automake1.6 automake1.7 automake1.8 automake1.9 automake1.10 automake1.11 automake1.12 automake1.13 automake1.14 automake1.15 cygwin -- 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
setup.exe with packages specified downloads multiple versions [?]
As a note, running this: setup-x86.exe ^ --quiet-mode ^ --no-admin ^ --no-startmenu ^ --no-shortcuts ^ --no-desktop ^ --site http://mirrors.xmission.com/cygwin/ ^ --root %cd% ^ --packages ^ ed,curl,wget,subversion,texinfo,gcc-g++,bison,flex,cvs,yasm,automake,libtool,autoconf,gcc-core,cmake,git,make,pkg-config,zlib1g-dev,mercurial,unzip,pax,ncurses,patch downloads seemingly lots of versions of particular packages [?] (note the duplicates of autoconf and automake, various versions: Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin %2f/x86/release/autoconf/autoconf-13-1.tar.bz2 Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin %2f/x86/release/autoconf2.1/autoconf2.1-2.13-12.tar.bz2 Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin %2f/x86/release/autoconf2.5/autoconf2.5-2.69-3.tar.xz Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin %2f/x86/release/automake/automake-9-1.tar.bz2 Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin %2f/x86/release/automake1.10/automake1.10-1.10.3-2.tar.bz2 Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin %2f/x86/release/automake1.11/automake1.11-1.11.6-2.tar.bz2 Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm peg_local_builds\cygwin_local_install/http%3a%2f%2fmirrors.xmission.com%2fcygwin %2f/x86/release/automake1.12/automake1.12-1.12.6-2.tar.bz2 Extracting from file://C:\dev\ruby\ffmpeg-windows-build-helpers\native_build\ffm Not sure if that's expected or not. Cheers! -roger- -- 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: xfig-3.2.5c-2.x86_64 crashes on save as or export on windows 10
Hi too, it crashes on x_86 (i.e. 32 bit version) too, even after re-installing the xorg-server packages. xfig won't show the export window before it crashes. What else can I do? Any step-by-step procedure with xorg-server renewal? Is there an issue with Athena widgets? Cheers Hans-Georg Hi, A follow up. I down leveled the xorg-server* (5 packages from 1.17.2-4 to 1.17.2-3 -common, -devel, -dmx, -extra + servers) and this bad behavior goes away (Xfig saves as and/or exports files). There is a segfault when it exits & some complaints re missing fonts (?) but I can function. Cheers, Steve -- 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: Bug in collation functions?
On 10/29/2015 12:51 PM, Eric Blake wrote: On 10/29/2015 10:13 AM, Ken Brown wrote: Never mind. My test case was flawed, because it didn't check for the possibility that wcscoll might return 0. Here's a revised definition of the "compare" function: void compare (const wchar_t *a, const wchar_t *b, const char *loc) { setlocale (LC_COLLATE, loc); int res = wcscoll (a, b); char c = res < 0 ? '<' : res > 0 ? '>' : '='; printf ("\"%ls\" %c \"%ls\" in %s locale\n", a, c, b, loc); } With this change (and the use of NORM_IGNORESYMBOLS) the test returns the following on Cygwin: $ ./wcscoll_test "11" > "1.1" in POSIX locale "11" = "1.1" in en_US.UTF-8 locale "11" > "1 2" in POSIX locale "11" < "1 2" in en_US.UTF-8 locale It still differs from Linux, but it's good enough to make the emacs test pass. Moreover, this behavior actually seems more reasonable to me than the Linux behavior. After all, if you're ignoring punctuation, how can you decide which of "11" or "1.1" comes first? Careful. POSIX is proposing some wording that say that normal locales should always implement a fallback of last resort (and that locales that do not do so should have a special name including '@', to make it obvious). It is not standardized yet, but worth thinking about. http://austingroupbugs.net/view.php?id=938 http://austingroupbugs.net/view.php?id=963 The intent of that wording is that if ignoring punctuation could cause two strings to otherwise compare equal, the fallback of a total ordering on all characters means that the final result of strcoll() will not be 0 unless the two strings are identical. In that case, I think Cygwin should start by using NORM_IGNORESYMBOLS in non-POSIX locales, with the goal of eventually moving toward emulating glibc. I don't know what fallback glibc uses or how hard it would be to implement this on Cygwin. Here's a tangentially related issue, also motivated by a failing emacs test: Should setlocale return null to indicate an error if it's given an invalid locale name? This happens on Linux but not on Cygwin, as the following modified test case shows: $ cat wcscoll_test.c #include #include #include void compare (const wchar_t *a, const wchar_t *b, const char *loc) { if (! setlocale (LC_COLLATE, loc)) printf ("Unable to set locale to %s\n", loc); else { int res = wcscoll (a, b); char c = res < 0 ? '<' : res > 0 ? '>' : '='; printf ("\"%ls\" %c \"%ls\" in %s locale\n", a, c, b, loc); } } int main () { compare (L"11", L"1.1", "POSIX"); compare (L"11", L"1.1", "en_US.UTF-8"); compare (L"11", L"1 2", "POSIX"); compare (L"11", L"1 2", "en_US.UTF-8"); compare (L"11", L"1 2", "en_DE.UTF-8"); } On Cygwin (with NORM_IGNORESYMBOLS), the output is "11" > "1.1" in POSIX locale "11" = "1.1" in en_US.UTF-8 locale "11" > "1 2" in POSIX locale "11" < "1 2" in en_US.UTF-8 locale "11" < "1 2" in en_DE.UTF-8 locale but on Linux it is "11" > "1.1" in POSIX locale "11" < "1.1" in en_US.UTF-8 locale "11" > "1 2" in POSIX locale "11" < "1 2" in en_US.UTF-8 locale Unable to set locale to en_DE.UTF-8 Ken -- 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: initial cygwin installation
On Oct 28, 2015, at 8:49 PM, Andrey Repin wrote: > >> I only wanted to *reinstall* >> everything I had installed previously > > Solution is to run `cygcheck --check-setup` and manually select any packages > reported incomplete for reinstall. This solution and Achim Gratz’ assume your Cygwin installation still runs. If your AV has so totally roached things that you can’t even get a bash prompt up, or run your text editor, or run sed, you still have one way to avoid reinstalling everything without guessing: Open c:\cygwin64\bin in Windows Explorer, and use the file listing you find there to choose packages to reinstall. Many of these will belong to some umbrella package, like coreutils or cygutils, so use the Cygwin Package search engine to work out what to reinstall if you’re not sure: https://cygwin.com/packages Searching for something like “ls” will return too many results. Making it “ls.exe” helps, but will still include false positives. But, searching for “/ls.exe” tells you what you want to know: it’s in coreutils. -- 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: tiff-4.0.6-1
The following packages have been updated for both arches: * tiff-4.0.6-1 * tiff-doc-4.0.6-1 * tiff-opengl-4.0.6-1 * libtiff6-4.0.6-1 * libtiff-devel-4.0.6-1 libtiff is the reference implementation for reading and writing TIFF images, along with a small collection of tools for doing simple manipulations of TIFF images on UNIX systems, and documentation on the library and tools. This is an update to the latest upstream release. -- Yaakov -- 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: poppler-0.36.0-2
The following packages have been updated for both arches: * poppler-0.36.0-2 * libpoppler55-0.36.0-2 * libpoppler-devel-0.36.0-2 * libpoppler-cpp0-0.36.0-2 * libpoppler-cpp-devel-0.36.0-2 * libpoppler-glib8-0.36.0-2 * libpoppler-glib-devel-0.36.0-2 * libpoppler-glib-doc-0.36.0-2 * girepository-Poppler0.18-0.36.0-2 * libpoppler-qt4_4-0.36.0-2 * libpoppler-qt4-devel-0.36.0-2 * libpoppler-qt5_1-0.36.0-2 * libpoppler-qt5-devel-0.36.0-2 Poppler is a suite of PDF rendering libraries and utilities based on the xpdf-3.0 code base. This release re-enables OpenJPEG support. -- Yaakov -- 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] New: openjpeg2-2.1.0-1
The following packages have been added to the Cygwin distribution: * openjpeg2-2.1.0-1 * libopenjp2_7-2.1.0-1 * libopenjp2-devel-2.1.0-1 * libopenjp2-doc-2.1.0-1 The OpenJPEG library is an open-source JPEG 2000 codec written in C language. It has been developed in order to promote the use of JPEG 2000, the new still-image compression standard from the Joint Photographic Experts Group (JPEG). This is a new major release of the OpenJPEG library, and is parallel installable with the 1.5 version still in use. -- Yaakov -- 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: packages rebuilt for exiv2-0.25, openexr-2.2.0
The following packages (and their subpackages) have been updated, having been rebuilt for exiv2-0.25 and/or openexr-2.2.0: * calligra-2.9.8-2 * gegl-0.2.0-9 * gwenview-4.14.3-3 * kdelibs-4.14.13-1 * kde-runtime-15.04.3-2 * kf5-kimageformats-5.12.0-2 * kfilemetadata-4.14.3-2 * libkexiv2-15.04.3-2 * pdf2djvu-0.9.1-2 * strigi-0.7.8-5 * ufraw-0.22-2 -- Yaakov -- 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: pixman-0.32.8-1
The following packages have been updated in the Cygwin distribution: * libpixman1_0-0.32.8-1 * libpixman1-devel-0.32.8-1 pixman is a library that provides low-level pixel manipulation features such as image compositing and trapezoid rasterization. It is used primarily by the cairo library and the X servers. This is an update to the latest upstream stable release, which includes a fix for a potential stack overflow (which, FWIW, I have been unable to reproduce on Cygwin): https://bugs.freedesktop.org/show_bug.cgi?id=92027 -- Yaakov -- 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: Bug in collation functions?
On 10/29/2015 10:13 AM, Ken Brown wrote: > Never mind. My test case was flawed, because it didn't check for the > possibility that wcscoll might return 0. Here's a revised definition of > the "compare" function: > > void > compare (const wchar_t *a, const wchar_t *b, const char *loc) > { > setlocale (LC_COLLATE, loc); > int res = wcscoll (a, b); > char c = res < 0 ? '<' : res > 0 ? '>' : '='; > printf ("\"%ls\" %c \"%ls\" in %s locale\n", a, c, b, loc); > } > > With this change (and the use of NORM_IGNORESYMBOLS) the test returns > the following on Cygwin: > > $ ./wcscoll_test > "11" > "1.1" in POSIX locale > "11" = "1.1" in en_US.UTF-8 locale > "11" > "1 2" in POSIX locale > "11" < "1 2" in en_US.UTF-8 locale > > It still differs from Linux, but it's good enough to make the emacs test > pass. Moreover, this behavior actually seems more reasonable to me than > the Linux behavior. After all, if you're ignoring punctuation, how can > you decide which of "11" or "1.1" comes first? Careful. POSIX is proposing some wording that say that normal locales should always implement a fallback of last resort (and that locales that do not do so should have a special name including '@', to make it obvious). It is not standardized yet, but worth thinking about. http://austingroupbugs.net/view.php?id=938 http://austingroupbugs.net/view.php?id=963 The intent of that wording is that if ignoring punctuation could cause two strings to otherwise compare equal, the fallback of a total ordering on all characters means that the final result of strcoll() will not be 0 unless the two strings are identical. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
RE: pthread_kill: signals remain pending after target thread exits
> From: Corinna Vinschen [corinna-cyg...@cygwin.com] > Sent: Thursday, October 29, 2015 1:02 AM > On Oct 28 10:14, Corinna Vinschen wrote: ... > > > Thanks; that was fast! I tried replacing cygwin1.dll with > > > cygwin1-20151023.dll . > > > > > > The original test case now works. I checked some of my other tests, > > > and unfortunately some of them failed, so I extracted out a new test > > > case, which is attached. My guess is that something is subtly different > > > about the timing on this test. > > > > Is this a regression? Did it work with 2.2.1? > > Answering myself here, this didn't work at all in 2.2.1. I can > reproduce the problem and I'm going to take a look. Not sure if > there's a quick solution, though. This looks like a deadlock > situation. The signal definitely got send, I just don't see yet > why it's not handled in wait_sig. Yes, test_pending_signal2.c fails in 2.2.1, though the symptoms differ: there is no Cygwin process left hanging that cannot be killed by a Cygwin signal. But both tests appear to pass in Cygwin 1.7.9, so in that sense it is a regression, just not a recent one. -- John Carey -- 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: audiofile-0.3.6-2
The following packages have been updated in the Cygwin distribution: * audiofile-0.3.6-2 * libaudiofile1-0.3.6-2 * libaudiofile-devel-0.3.6-2 The Audio File Library provides a uniform programming interface to standard digital audio file formats. This library allows the processing of audio data to and from audio files of many common formats (currently AIFF, AIFF-C, WAVE, NeXT/Sun .snd/.au, IRCAM, AVR, Amiga IFF/8SVX, and NIST SPHERE). The library also supports compression (currently G.711 mu-law and A-law and IMA and MS ADPCM) as well as PCM formats of all flavors (signed and unsigned integer, single- and double-precision floating point). This release includes a patch for CVE-2015-7747: https://bugzilla.redhat.com/show_bug.cgi?id=1269766 -- Yaakov -- 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] New: lz4-131-1
The following packages have been added to the Cygwin distribution: * lz4-131-1 * liblz4_1-131-1 * liblz4-devel-131-1 LZ4 is a lossless compression algorithm, providing compression speed at 400 MB/s per core. It features an extremely fast decoder, with speed in multiple GB/s per core. A high compression derivative, called LZ4_HC, is available, trading customizable CPU time for compression ratio. -- Yaakov -- 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: exiv2-0.25-1
The following packages have been updated in the Cygwin distribution: * exiv2-0.25-1 * libexiv2_14-0.25-1 * libexiv2-devel-0.25-1 Exiv2 is a C++ library and a command line utility to manage image metadata. It provides fast and easy read and write access to the Exif, IPTC and XMP metadata of digital images in various formats. This is an update to the latest upstream release, with an ABI version bump to the library. Packages dependent on the previous version of the library are in the process of being rebuilt. -- Yaakov -- 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: Bug in collation functions?
On 10/29/2015 11:45 AM, Ken Brown wrote: On 10/29/2015 11:35 AM, Corinna Vinschen wrote: On Oct 29 08:59, Ken Brown wrote: On 10/29/2015 4:30 AM, Corinna Vinschen wrote: On Oct 29 08:50, Corinna Vinschen wrote: On Oct 28 21:58, Eric Blake wrote: On 10/28/2015 04:14 PM, Ken Brown wrote: It's my understanding that collation is supposed to take whitespace and punctuation into account in the POSIX locale but not in other locales. Not quite right. It is up to the locale definition whether whitespace affects collation. But you are correct that in the POSIX locale, whitespace must not be ignored in collation. This doesn't seem to be the case on Cygwin. Here's a test case using wcscoll, but the same problem occurs with strcoll. That's because the locale definitions are different in cygwin than they are in glibc. But it is not a bug in Cygwin; POSIX allows for different systems to have different locale definitions while still using the same locale name like en_US.UTF-8. Btw, strcoll and wcscoll in Cygwin are implemented using the Windows function CompareStringW with the LCID set to the locale matching the POSIX locale setting. I'm rather glad I didn't have to implement this by myself... :} OTOH, CompareString has a couple of flags to control its behaviour, see https://msdn.microsoft.com/en-us/library/windows/desktop/dd317761%28v=vs.85%29.aspx Right now Cygwin calls CompareStringW with dwCmpFlags set to 0, but there are flags like NORM_IGNORENONSPACE, NORM_IGNORESYMBOLS. I'm open to a discussion how to change the settings to more closely resemble the rules on Linux. E.g. wcscoll simply calls wcscmp rather than CompareStringW for the C/POSIX locale anyway. So, would it makes sense to set the flags to NORM_IGNORESYMBOLS in other locales? I think so. That's what the native Windows build of emacs does in this situation. Is that all it's doing? I'm asking because using NORM_IGNORESYMBOLS does not exaclty resemble the behaviour on Linux on my W10 box: "11" > "1.1" in POSIX locale !!! "11" > "1.1" in en_US.UTF-8 locale "11" > "1 2" in POSIX locale "11" < "1 2" in en_US.UTF-8 locale I just noticed that myself and was going to ask about that difference. I don't see anything else that emacs is doing on native Windows. But in the test I referred to above, the locale is set to "enu_USA" in the native Windows build. Does that explain the discrepancy? If not, I can ask on the emacs-devel list whether the test passes on Windows. Never mind. My test case was flawed, because it didn't check for the possibility that wcscoll might return 0. Here's a revised definition of the "compare" function: void compare (const wchar_t *a, const wchar_t *b, const char *loc) { setlocale (LC_COLLATE, loc); int res = wcscoll (a, b); char c = res < 0 ? '<' : res > 0 ? '>' : '='; printf ("\"%ls\" %c \"%ls\" in %s locale\n", a, c, b, loc); } With this change (and the use of NORM_IGNORESYMBOLS) the test returns the following on Cygwin: $ ./wcscoll_test "11" > "1.1" in POSIX locale "11" = "1.1" in en_US.UTF-8 locale "11" > "1 2" in POSIX locale "11" < "1 2" in en_US.UTF-8 locale It still differs from Linux, but it's good enough to make the emacs test pass. Moreover, this behavior actually seems more reasonable to me than the Linux behavior. After all, if you're ignoring punctuation, how can you decide which of "11" or "1.1" comes first? Ken -- 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: Bug in collation functions?
On 10/29/2015 09:35 AM, Corinna Vinschen wrote: >>> Right now Cygwin calls CompareStringW with dwCmpFlags set to 0, but there >>> are flags like NORM_IGNORENONSPACE, NORM_IGNORESYMBOLS. I'm open to a >>> discussion how to change the settings to more closely resemble the rules >>> on Linux. >>> >>> E.g. wcscoll simply calls wcscmp rather than CompareStringW for the >>> C/POSIX locale anyway. So, would it makes sense to set the flags to >>> NORM_IGNORESYMBOLS in other locales? >> >> I think so. That's what the native Windows build of emacs does in this >> situation. > > Is that all it's doing? I'm asking because using NORM_IGNORESYMBOLS > does not exaclty resemble the behaviour on Linux on my W10 box: > > "11" > "1.1" in POSIX locale > !!! "11" > "1.1" in en_US.UTF-8 locale > "11" > "1 2" in POSIX locale > "11" < "1 2" in en_US.UTF-8 locale > I'm not sure if blindly enabling the flags for all locales makes sense, though. I haven't audited glibc locales to know for sure, but it is my impression that it is up to the locale author on whether whitespace affects collation; and while the author of glibc en_US.UTF-8 may have chosen that way, I can't guarantee that some other locales in glibc still treat whitespace as significant. POSIX has a notion of writing your own locale definition - and glibc definitely supports that (although I haven't personally tried doing it), where you can set your OWN collation rules while inheriting the bulk of the work from an existing locale. So in glibc, it is possible to have a locale similar to en_US.UTF-8 but where whitespace IS significant in collation. I know cygwin isn't there yet (we expose the Windows locale, but do not let you define your own). This seems like the sort of thing where maybe we'd want support for user-defined locales, compiled into a binary format, and then cygwin opens the binary locale definition for deciding which flags to use according to the locale being used. But that sounds like a LOT of work, for a questionable amount of gain. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Bug in collation functions?
On 10/29/2015 11:35 AM, Corinna Vinschen wrote: On Oct 29 08:59, Ken Brown wrote: On 10/29/2015 4:30 AM, Corinna Vinschen wrote: On Oct 29 08:50, Corinna Vinschen wrote: On Oct 28 21:58, Eric Blake wrote: On 10/28/2015 04:14 PM, Ken Brown wrote: It's my understanding that collation is supposed to take whitespace and punctuation into account in the POSIX locale but not in other locales. Not quite right. It is up to the locale definition whether whitespace affects collation. But you are correct that in the POSIX locale, whitespace must not be ignored in collation. This doesn't seem to be the case on Cygwin. Here's a test case using wcscoll, but the same problem occurs with strcoll. That's because the locale definitions are different in cygwin than they are in glibc. But it is not a bug in Cygwin; POSIX allows for different systems to have different locale definitions while still using the same locale name like en_US.UTF-8. Btw, strcoll and wcscoll in Cygwin are implemented using the Windows function CompareStringW with the LCID set to the locale matching the POSIX locale setting. I'm rather glad I didn't have to implement this by myself... :} OTOH, CompareString has a couple of flags to control its behaviour, see https://msdn.microsoft.com/en-us/library/windows/desktop/dd317761%28v=vs.85%29.aspx Right now Cygwin calls CompareStringW with dwCmpFlags set to 0, but there are flags like NORM_IGNORENONSPACE, NORM_IGNORESYMBOLS. I'm open to a discussion how to change the settings to more closely resemble the rules on Linux. E.g. wcscoll simply calls wcscmp rather than CompareStringW for the C/POSIX locale anyway. So, would it makes sense to set the flags to NORM_IGNORESYMBOLS in other locales? I think so. That's what the native Windows build of emacs does in this situation. Is that all it's doing? I'm asking because using NORM_IGNORESYMBOLS does not exaclty resemble the behaviour on Linux on my W10 box: "11" > "1.1" in POSIX locale !!! "11" > "1.1" in en_US.UTF-8 locale "11" > "1 2" in POSIX locale "11" < "1 2" in en_US.UTF-8 locale I just noticed that myself and was going to ask about that difference. I don't see anything else that emacs is doing on native Windows. But in the test I referred to above, the locale is set to "enu_USA" in the native Windows build. Does that explain the discrepancy? If not, I can ask on the emacs-devel list whether the test passes on Windows. Ken -- 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: Bug in collation functions?
On Oct 29 08:59, Ken Brown wrote: > On 10/29/2015 4:30 AM, Corinna Vinschen wrote: > >On Oct 29 08:50, Corinna Vinschen wrote: > >>On Oct 28 21:58, Eric Blake wrote: > >>>On 10/28/2015 04:14 PM, Ken Brown wrote: > It's my understanding that collation is supposed to take whitespace and > punctuation into account in the POSIX locale but not in other locales. > >>> > >>>Not quite right. It is up to the locale definition whether whitespace > >>>affects collation. But you are correct that in the POSIX locale, > >>>whitespace must not be ignored in collation. > >>> > This doesn't seem to be the case on Cygwin. Here's a test case using > wcscoll, but the same problem occurs with strcoll. > >>> > >>>That's because the locale definitions are different in cygwin than they > >>>are in glibc. But it is not a bug in Cygwin; POSIX allows for different > >>>systems to have different locale definitions while still using the same > >>>locale name like en_US.UTF-8. > >> > >>Btw, strcoll and wcscoll in Cygwin are implemented using the Windows > >>function CompareStringW with the LCID set to the locale matching the > >>POSIX locale setting. I'm rather glad I didn't have to implement this > >>by myself... :} > > > >OTOH, CompareString has a couple of flags to control its behaviour, see > >https://msdn.microsoft.com/en-us/library/windows/desktop/dd317761%28v=vs.85%29.aspx > > > >Right now Cygwin calls CompareStringW with dwCmpFlags set to 0, but there > >are flags like NORM_IGNORENONSPACE, NORM_IGNORESYMBOLS. I'm open to a > >discussion how to change the settings to more closely resemble the rules > >on Linux. > > > >E.g. wcscoll simply calls wcscmp rather than CompareStringW for the > >C/POSIX locale anyway. So, would it makes sense to set the flags to > >NORM_IGNORESYMBOLS in other locales? > > I think so. That's what the native Windows build of emacs does in this > situation. Is that all it's doing? I'm asking because using NORM_IGNORESYMBOLS does not exaclty resemble the behaviour on Linux on my W10 box: "11" > "1.1" in POSIX locale !!! "11" > "1.1" in en_US.UTF-8 locale "11" > "1 2" in POSIX locale "11" < "1 2" in en_US.UTF-8 locale Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpofEpwqtRBJ.pgp Description: PGP signature
Re: Unison 2.43.3 fails to synchronize execute permission bit
On Wed, Oct 28, 2015 at 2:55 PM, wrote: > When synchronizing two directories on the same NTFS-formatted drive, unison > (with -perms 0o1777) fails to set execute permissions on new files. (It also > fails to detect changes in execute permissions and to set them on existing > files.) >... I forgot cygcheck.out. I have attached it. Ms. Alex Hankins cygcheck.out Description: Binary data -- 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: How to run xinit without first entering a cygwin terminal
On 29/10/2015 06:25, Xuehan Xu wrote: Hi, everyone I'm trying to run xinit.exe to start a GUI program in a windows cmd prompt. The command I run: "c:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/xinit.exe /home/Administrator/rdesktop.exe -f 192.168.1.79 But, it seems that rdesktop.exe isn't running, the window was just showing a terminal prompt. Using the command lines from the start menu items created for the xinit package as a template (see [1]), I think you need something like: c:\cygwin\bin\run.exe -quote /usr/bin/bash.exe -l -c "/usr/bin/xinit.exe /home/Administrator/rdesktop.exe -f 192.168.1.79" The command string being given to bash -c needs quoting, otherwise subsequent words are assumed to be parameters to that command. run needs to be given the -quote option to protect those quotes. [1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-command-line-args -- Jon TURNEY Volunteer Cygwin/X X Server 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: Bug in collation functions?
On 10/29/2015 4:30 AM, Corinna Vinschen wrote: On Oct 29 08:50, Corinna Vinschen wrote: On Oct 28 21:58, Eric Blake wrote: On 10/28/2015 04:14 PM, Ken Brown wrote: It's my understanding that collation is supposed to take whitespace and punctuation into account in the POSIX locale but not in other locales. Not quite right. It is up to the locale definition whether whitespace affects collation. But you are correct that in the POSIX locale, whitespace must not be ignored in collation. This doesn't seem to be the case on Cygwin. Here's a test case using wcscoll, but the same problem occurs with strcoll. That's because the locale definitions are different in cygwin than they are in glibc. But it is not a bug in Cygwin; POSIX allows for different systems to have different locale definitions while still using the same locale name like en_US.UTF-8. Btw, strcoll and wcscoll in Cygwin are implemented using the Windows function CompareStringW with the LCID set to the locale matching the POSIX locale setting. I'm rather glad I didn't have to implement this by myself... :} OTOH, CompareString has a couple of flags to control its behaviour, see https://msdn.microsoft.com/en-us/library/windows/desktop/dd317761%28v=vs.85%29.aspx Right now Cygwin calls CompareStringW with dwCmpFlags set to 0, but there are flags like NORM_IGNORENONSPACE, NORM_IGNORESYMBOLS. I'm open to a discussion how to change the settings to more closely resemble the rules on Linux. E.g. wcscoll simply calls wcscmp rather than CompareStringW for the C/POSIX locale anyway. So, would it makes sense to set the flags to NORM_IGNORESYMBOLS in other locales? I think so. That's what the native Windows build of emacs does in this situation. (I came across the issue because one of the tests in the emacs test suite was failing on Cygwin.) Ken -- 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: gcc: cannot find -lubsan
On Wed, Oct 28, 2015 at 5:36 PM, Yaakov Selkowitz wrote: > > The various sanitizers in recent versions of GCC are not currently > supported on Cygwin. Then it would be nicer if GCC reported an error (rather than compile dozens of files and then fail to link them at the end). This is likely a GCC issue (I don't know whether GCC can be configured/built so it knows sanitizers are not supported). Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- 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: Bug in collation functions?
On Oct 29 08:50, Corinna Vinschen wrote: > On Oct 28 21:58, Eric Blake wrote: > > On 10/28/2015 04:14 PM, Ken Brown wrote: > > > It's my understanding that collation is supposed to take whitespace and > > > punctuation into account in the POSIX locale but not in other locales. > > > > Not quite right. It is up to the locale definition whether whitespace > > affects collation. But you are correct that in the POSIX locale, > > whitespace must not be ignored in collation. > > > > > This doesn't seem to be the case on Cygwin. Here's a test case using > > > wcscoll, but the same problem occurs with strcoll. > > > > That's because the locale definitions are different in cygwin than they > > are in glibc. But it is not a bug in Cygwin; POSIX allows for different > > systems to have different locale definitions while still using the same > > locale name like en_US.UTF-8. > > Btw, strcoll and wcscoll in Cygwin are implemented using the Windows > function CompareStringW with the LCID set to the locale matching the > POSIX locale setting. I'm rather glad I didn't have to implement this > by myself... :} OTOH, CompareString has a couple of flags to control its behaviour, see https://msdn.microsoft.com/en-us/library/windows/desktop/dd317761%28v=vs.85%29.aspx Right now Cygwin calls CompareStringW with dwCmpFlags set to 0, but there are flags like NORM_IGNORENONSPACE, NORM_IGNORESYMBOLS. I'm open to a discussion how to change the settings to more closely resemble the rules on Linux. E.g. wcscoll simply calls wcscmp rather than CompareStringW for the C/POSIX locale anyway. So, would it makes sense to set the flags to NORM_IGNORESYMBOLS in other locales? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpBBoG4l1oGB.pgp Description: PGP signature
Re: Proposal to use ThreadQuerySetWin32StartAddress inside munge_threadfunc (Cygwin randomly crashes on Wine)
On Oct 21 22:48, Qian Hong wrote: > Hi Corinna, > > On Wed, Oct 21, 2015 at 4:17 PM, Corinna Vinschen > wrote: > > I simplified your patch, taking out the printf's and added a test in the > > loop in case NtQueryInformationThread failed. See below. It's not > > overly large, but it introduces new functionality. It would be nice if > > you could sign a copyright assignment and send it as PDF. Please see > > https://cygwin.com/assign.txt. > > Thank you for the improvement! > I sent an email with my signed pdf to ges-info AT redhat DOT com and > CCed corinna-cygwin AT cygwin DOT com, but it was rejected by > corrina-cygwin AT cygwin DOT com, did I miss anything? All is well, patch applied. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpdFhIz24H59.pgp Description: PGP signature
Re: pthread_kill: signals remain pending after target thread exits
On Oct 28 10:14, Corinna Vinschen wrote: > On Oct 27 19:06, John Carey wrote: > > Sorry for the delay. > > > > From: Corinna Vinschen [corinna-cyg...@cygwin.com] > > Sent: Friday, October 23, 2015 5:55 AM > > > > I've attached a test case that I *think* gets into the right spot, at > > > > least for 64-bit Cygwin 2.0.4. That is, it hangs trying to receive > > > > the signal, instead of terminating. (This test passes (terminates) in > > > > 32-bit Cygwin 1.7.9 and 64-bit Ubuntu 14.04.3 LTS.) > > > > > > Thanks for the testcase. I applied a patch which hopefully works as > > > desired, at least to fix the immediate problem of the remaining pending > > > signal when a thread exits. I uploaded a new developer snapshot to > > > https://cygwin.com/snapshots. Please give it a try. > > > > Thanks; that was fast! I tried replacing cygwin1.dll with > > cygwin1-20151023.dll . > > > > The original test case now works. I checked some of my other tests, > > and unfortunately some of them failed, so I extracted out a new test > > case, which is attached. My guess is that something is subtly different > > about the timing on this test. > > Is this a regression? Did it work with 2.2.1? Answering myself here, this didn't work at all in 2.2.1. I can reproduce the problem and I'm going to take a look. Not sure if there's a quick solution, though. This looks like a deadlock situation. The signal definitely got send, I just don't see yet why it's not handled in wait_sig. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpA0erH9TLwn.pgp Description: PGP signature
Re: Bug in collation functions?
On Oct 28 21:58, Eric Blake wrote: > On 10/28/2015 04:14 PM, Ken Brown wrote: > > It's my understanding that collation is supposed to take whitespace and > > punctuation into account in the POSIX locale but not in other locales. > > Not quite right. It is up to the locale definition whether whitespace > affects collation. But you are correct that in the POSIX locale, > whitespace must not be ignored in collation. > > > This doesn't seem to be the case on Cygwin. Here's a test case using > > wcscoll, but the same problem occurs with strcoll. > > That's because the locale definitions are different in cygwin than they > are in glibc. But it is not a bug in Cygwin; POSIX allows for different > systems to have different locale definitions while still using the same > locale name like en_US.UTF-8. Btw, strcoll and wcscoll in Cygwin are implemented using the Windows function CompareStringW with the LCID set to the locale matching the POSIX locale setting. I'm rather glad I didn't have to implement this by myself... :} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpBeyjJoQCfN.pgp Description: PGP signature
Re: initial cygwin installation
Am 28.10.2015 um 21:38 schrieb Duncan Roe: As it happens, I also saw that message last night. I only wanted to *reinstall* everything I had installed previously, owing to AVG antivirus having deleted I don't know what. One way to do that (if you really want to re-install instead of running cygcheck and just re-install those packages listed as incomplete) is to edit /etc/setup/installed.db so that each package version listed there is "outdated". The next time you run setup it will upgrade everything, which is thre re-install you want. sed -re 's/( [a-zA-Z].*-.*-)[0-9]+\./\10./' \ -i.bak /etc/setup/installed.db -- Achim. (on the road :-) -- 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: Permissions on /var
On Oct 28 18:00, Jan Bruun Andersen wrote: > Looks good. No errors are reported on my end now. Thanks for testing. Corinna > > On 28 October 2015 at 14:28, Corinna Vinschen > wrote: > > On Oct 28 01:33, Jan Bruun Andersen wrote: > >> Today, as I installed inetutils (I needed telnet for Cygwin; telnet > >> for Windows 10 does nothing; no error, no nothing) I got an error from > >> setup-084_64. The error message directed me to look at > >> /var/log/setup.log.full. Here is the relevant part, very near the end: > >> [...] > >> I tracked the check down to a function in > >> /usr/share/csih/cygwin-service-installation-helper.sh. It checks the > >> permissions with a call to function csih_check_dir_perms which ends up > >> doing this: > > > > I just (belatedly) released a new version of the csih package, 0.9.9-1, > > which is supposed to fix this installation problem. > > > > > > HTH, > > Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpFQbjRhKiiP.pgp Description: PGP signature
Re: Bash unable to print epoch timestamp
On Oct 28 17:20, Brian Inglis wrote: > Corinna Vinschen cygwin.com> writes: > > On Oct 26 19:16, Brian Inglis wrote: > > > Sorry - redo with the file existing! > > > > No worries, I applied your other patch since it also cleaned up some > > whitespaces and, for some reason, the below patch didn't apply cleanly. > > Email paste may have converted tabs to spaces - need to work out how to > email inline text attachments without tab expansion in tbird - paste on > gmane (below) seems to retain tabs - may try that in future. > > > There was just one problem: > > > > > + { > > > + long offset;/* offset < 0 => W of GMT, > 0 => E of GMT: > > > + offset = 0;subtract to get UTC */ > > > > This setting the offset to 0 is necessary, but commented out. Typo? > > I fixed this before committing the patch. > > Thanks - total brain fart - Doh! Interesting that gcc -Wall -Wextra did not > catch this - used to be reliable warning about conditionally uninitialized > variables! > > Please check that the second set of tests in Vec1 includes the following, as > it was not in my very first patch email, which you may not have received: > @@ -1502,6 +1575,7 @@ const struct test Vec1[] = { > { CQ("%p"), 2+1, EXP(CQ("PM")) }, > { CQ("%r"), 11+1, EXP(CQ("11:01:13 PM")) }, > { CQ("%R"), 5+1, EXP(CQ("23:01")) }, > + { CQ("%s"), 2+1, EXP(CQ("1215054073")) }, > { CQ("%S"), 2+1, EXP(CQ("13")) }, > { CQ("%t"), 1+1, EXP(CQ("\t")) }, > { CQ("%T"), 8+1, EXP(CQ("23:01:13")) }, Check. This was in your patch so it's upstream now. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpJ2Uo9Z5615.pgp Description: PGP signature