libevent update ?
Hi Yaakov, can you update to latest libevent-2.0.22 ? Regards Marco -- 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: libevent update ?
On Fri, 2015-12-25 at 07:55 +0100, Marco Atzeri wrote: > Hi Yaakov, > can you update to latest libevent-2.0.22 ? https://www.mail-archive.com/cygwin-ports-general@lists.sourceforge.net /msg01396.html -- 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: stat() lstat() not able to read long filename with cyrillic chars?
Greetings, Corinna Vinschen! >> First, I have read the FAQ and this mailing archive :) >> >> Here is the problem I meet: >> >> In a directory are placed three files using windows 8's explorer: >> - a short Cyrillic filename "абваб.txt" >> - a long Cyrillic filename >> "абвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабваб.txt" >> - a long Latin filename >> "ababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababa.txt" >> >> >> >From a C program compiled under Cygwin, I can obtain the corresponding >> filename strings using readdir_r()... >> >> "\320\260\320\261\320\262\320\260\320\261.txt" >> "\320\260\320\261\320\262\320\260\320\261\320\262\320\260\320\261 [snipped]" >> "abababababaababababa [snipped]" >> >> ... but passing these strings in turn to lstat() or stat() returns 0 as >> expected for all except for the long Cyrillic filename. > NAME_MAX is 255. On Windows this is the number of UTF-16 chars > unfortunately. On POSIX systems (as on Cygwin) this is the number of > bytes. Long UTF-16 strings in cyrillic take twice as much UTF-8 chars > as it has UTF-16 chars, so NAME_MAX in utf-8 cyrillics translates into > a maximum of 127 UTF-16 chars. Aren't POSIX restrictions are a bit different? Namely 128 bytes per path element and 4096 bytes for file name? > If you need access to UTF-16 filenames with more characters, you can > switch to a one-byte charset temporarily, e.g. > $ LC_ALL=ru_RU your_app > to switch to iso-8859-5 or > $ LC_ALL=ru_RU.CP1251 > to switch to Windows codepage 1251. See > https://cygwin.com/cygwin-ug-net/setup-locale.html > HTH, > Corinna -- With best regards, Andrey Repin Friday, December 25, 2015 03:03:51 Sorry for my terrible english...
Re: Default locale for Russian/Russia should be ru_RU.CP1251
On Dec 24 18:40, Andrey ``Bass'' Shcheglov wrote: > Hi, > > I'm running Cygwin 2.2.0 on an English Windows 8.1 box: > > > CYGWIN_NT-6.3 UNIT-725 2.2.0(0.289/5/3) 2015-08-03 12:51 x86_64 Cygwin > > Windows regional settings are set to Russian/Russia. > > In the absence of any settings in bashrc/bash_profile, `locale` command > outputs the following: > > > LANG=ru_RU > > LC_CTYPE="ru_RU" > > LC_NUMERIC="ru_RU" > > LC_TIME="ru_RU" > > LC_COLLATE="ru_RU" > > LC_MONETARY="ru_RU" > > LC_MESSAGES="ru_RU" > > LC_ALL= > > This is perfectly fine, except that "no charset" in the locale output > means "ISO charset", which is ISO-8859-5 for Russian/Russia and has > never been used (historically, DOS used CP866, Windows used CP1251 ANSI > codepage, and various Unices sticked to KOI8-R before the rise of > Unicode era). Well, not quite. Cygwin is following Linux here: linux$ locale -av [...] locale: ru_RU archive: /usr/lib/locale/locale-archive -- title | Russian locale for Russia source | RAP address | Sankt Jorgens Alle 8, DK-1615 Kobenhavn V, Danmark email | bug-glibc-loca...@gnu.org language | Russian territory | Russia revision | 1.0 date | 2000-06-29 codeset | ISO-8859-5 cygwin$ locale -av [...] locale: ru_RU archive: /mnt/c/WINDOWS/system32/KERNEL32.DLL -- language | Russian territory | Russia codeset | ISO-8859-5 > Cygwin docs state that > > > Starting with Cygwin 1.7.2, the default character set is determined by the > > default Windows ANSI codepage for this language and territory. You missed to read on: Cygwin uses a character set which is the typical Unix-equivalent to the Windows ANSI codepage. For instance: [...] > which is not true in my case (Windows ANSI codepage for Cyrillic is > CP1251, not ISO-8859-5!). Rephrasing the above, Cygwin only uses the ANSI codepage to fetch the default Linux codepage from there. Maybe the documentation is a bit fuzzy, but it didn't say the charset is set *to* the Windows ANSI charset, it just *uses* the information to compute and set the codeset to the equivalent Linux codeset. > Surprisingly, for Belarusian (a.k.a > Belorussian, Eastern Slavic language very close to Russian) "be_BY" > locale the default charset is indeed CP1251 which is in accordance with > both the documentation and common sense. See the docs: The default charset of the "be_BY" locale (Belarusian/Belarus) is CP1251. With the "@latin" modifier it's UTF-8. Just as on Linux. > Despite that, $(locale -u) returns "en_GB", despite all regional > settings are set to Russian/Russia. I believe this is not correct, > either, and needs to be fixed. The locale is directly taken from the Windows system function GetUserDefaultUILanguage() in case of the -u option(*), and from GetUserDefaultLCID() in case of the -f option(**). This value is then fed into the Windows function GetLocaleInfo()(***) to fetch language and territory codes and that's what locale -u/-f prints. So, looks like you're using a UK-english system with just the region settings changed to Russia. In general UTF-8 is the preferred codeset so setting LANG to ru_RU.utf8 (locale -fU should work for you) is the better choice. Corinna (*) https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/utils/locale.cc;h=fadf3f3dacedad6474c92aabe826620b2677e494;hb=HEAD#l805 (**) https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/utils/locale.cc;h=fadf3f3dacedad6474c92aabe826620b2677e494;hb=HEAD#l812 (**) https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=winsup/utils/locale.cc;h=fadf3f3dacedad6474c92aabe826620b2677e494;hb=HEAD#l114 -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: stat() lstat() not able to read long filename with cyrillic chars?
On Dec 23 20:44, Denis Corbin wrote: > Hi, > > First, I have read the FAQ and this mailing archive :) > > Here is the problem I meet: > > In a directory are placed three files using windows 8's explorer: > - a short Cyrillic filename "абваб.txt" > - a long Cyrillic filename > "абвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабвабваб.txt" > - a long Latin filename > "ababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababa.txt" > > > >From a C program compiled under Cygwin, I can obtain the corresponding > filename strings using readdir_r()... > > "\320\260\320\261\320\262\320\260\320\261.txt" > "\320\260\320\261\320\262\320\260\320\261\320\262\320\260\320\261 [snipped]" > "abababababaababababa [snipped]" > > ... but passing these strings in turn to lstat() or stat() returns 0 as > expected for all except for the long Cyrillic filename. NAME_MAX is 255. On Windows this is the number of UTF-16 chars unfortunately. On POSIX systems (as on Cygwin) this is the number of bytes. Long UTF-16 strings in cyrillic take twice as much UTF-8 chars as it has UTF-16 chars, so NAME_MAX in utf-8 cyrillics translates into a maximum of 127 UTF-16 chars. If you need access to UTF-16 filenames with more characters, you can switch to a one-byte charset temporarily, e.g. $ LC_ALL=ru_RU your_app to switch to iso-8859-5 or $ LC_ALL=ru_RU.CP1251 to switch to Windows codepage 1251. See https://cygwin.com/cygwin-ug-net/setup-locale.html HTH, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: rxvt for cygwin64?
On 12/24/2015 3:27 AM, Marco Atzeri wrote: > > > On 24/12/2015 09:12, qrasmfu...@snkmail.com wrote: >> I've been using cygwin's rxvt (without X) for years, and prefer it to >> mintty both because I use rxvt on all my linux machines and because >> I've never liked putty. Despite most (but not all) of my Windows >> machines running 64-but windows7, I've procrastinated on switching to >> cygwin64, but I recently had to replace my laptop with a new Windows >> 10 machine, and figured I might as well install cygwin64. Everything >> went well until I discovered rxvt is not available in 64-bit. I found >> this thread (https://cygwin.com/ml/cygwin/2013-09/msg00016.html) from >> 9/2013 in the archives, but there doesn't seem to have been any >> resolution. >> >> Is there any plan to port rxvt to cygwin64? > > no plan. > rxvt is dead upstream, and rxvt without X is a hell and without > a maintainer by long time > Uhm not really a hell but is troublesome. You need to build the windows X emulation pieces first. The fact that upstream maintenance is dead will be a bigger issue. There may need to be items you need to deal with at the 64bit level. > mintty is a much better solution and with an active maintainer > Your opinion on the bike shed color but the fact that there is active development is a plus. -- cyg 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: Default locale for Russian/Russia should be ru_RU.CP1251
On 24/12/2015 16:40, Andrey ``Bass'' Shcheglov wrote:
Hi,
I'm running Cygwin 2.2.0 on an English Windows 8.1 box:
CYGWIN_NT-6.3 UNIT-725 2.2.0(0.289/5/3) 2015-08-03 12:51 x86_64 Cygwin
Windows regional settings are set to Russian/Russia.
In the absence of any settings in bashrc/bash_profile, `locale` command
outputs the following:
LANG=ru_RU
LC_CTYPE="ru_RU"
LC_NUMERIC="ru_RU"
LC_TIME="ru_RU"
LC_COLLATE="ru_RU"
LC_MONETARY="ru_RU"
LC_MESSAGES="ru_RU"
LC_ALL=
This is perfectly fine, except that "no charset" in the locale output
means "ISO charset", which is ISO-8859-5 for Russian/Russia and has
never been used (historically, DOS used CP866, Windows used CP1251 ANSI
codepage, and various Unices sticked to KOI8-R before the rise of
Unicode era).
The above is consistent with locale charmap output, which is again
ISO-8859-5.
Short C example also confirms ISO-8859-5 is used:
#include
#include
#include
int main() {
const char *locale = setlocale(LC_ALL, "");
const char *codeset = nl_langinfo(CODESET);
printf("locale: %s\n", locale);
printf("codeset: %s\n", codeset);
return 0;
}
outputs
locale: ru_RU/ru_RU/ru_RU/ru_RU/ru_RU/C
codeset: ISO-8859-5
Cygwin docs state that
Starting with Cygwin 1.7.2, the default character set is determined by the
default Windows ANSI codepage for this language and territory.
which is not true in my case (Windows ANSI codepage for Cyrillic is
CP1251, not ISO-8859-5!). Surprisingly, for Belarusian (a.k.a
Belorussian, Eastern Slavic language very close to Russian) "be_BY"
locale the default charset is indeed CP1251 which is in accordance with
both the documentation and common sense.
Additionally, in `strace locale -u` output, I see multiple
__get_lcid_from_locale: LCID=0x0419
lines.
"0x0419" corresponds to Russian/Russia (see
).
Despite that, $(locale -u) returns "en_GB", despite all regional
settings are set to Russian/Russia. I believe this is not correct,
either, and needs to be fixed.
the current code on
winsup/cygwin/nlsfuncs.cc
is responsible for the ISO-8859-5 defaults.
--
case 1251:
if (lcid == 0x0c1a/* sr_CS (Serbian Language/Former
Serbia and Montenegro) */
|| lcid == 0x1c1a /* sr_BA (Serbian Language/Bosnia
and Herzegovina) */
|| lcid == 0x281a /* sr_RS (Serbian
Language/Serbia) */
|| lcid == 0x301a /* sr_ME (Serbian
Language/Montenegro)*/
|| lcid == 0x0440 /* ky_KG (Kyrgyz/Kyrgyzstan) */
|| lcid == 0x0843 /* uz_UZ (Uzbek/Uzbekistan) */
/* tt_RU (Tatar/Russia),
IQTElif alphabet */
|| (lcid == 0x0444 && has_modifier ("@iqtelif"))
|| lcid == 0x0450)/* mn_MN (Mongolian/Mongolia) */
cs = "UTF-8";
else if (lcid == 0x0423) /* be_BY (Belarusian/Belarus) */
cs = has_modifier ("@latin") ? "UTF-8" : "CP1251";
else if (lcid == 0x0402) /* bg_BG (Bulgarian/Bulgaria) */
cs = "CP1251";
else if (lcid == 0x0422) /* uk_UA (Ukrainian/Ukraine) */
cs = "KOI8-U";
else
cs = "ISO-8859-5";
--
Regards,
Andrey.
as temporary workaround can you use UTF-8 ?
export LANG=ru_RU.UTF-8
Regards
Marco
--
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: rxvt for cygwin64?
On 24/12/2015 19:11, cyg Simple wrote: On 12/24/2015 3:27 AM, Marco Atzeri wrote: Is there any plan to port rxvt to cygwin64? no plan. rxvt is dead upstream, and rxvt without X is a hell and without a maintainer by long time Uhm not really a hell but is troublesome. You need to build the windows X emulation pieces first. The fact that upstream maintenance is dead will be a bigger issue. There may need to be items you need to deal with at the 64bit level. mintty is a much better solution and with an active maintainer Your opinion on the bike shed color but the fact that there is active development is a plus. As mintty is the default is a bit more than my preferred bike color. No one is maintaining "rxvt without X" or trying to port it on 64bit so it seems to me a clear indication of a hell of issue. Feel free to work on it, anyway Regards Marco -- 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
rxvt for cygwin64?
I've been using cygwin's rxvt (without X) for years, and prefer it to mintty both because I use rxvt on all my linux machines and because I've never liked putty. Despite most (but not all) of my Windows machines running 64-but windows7, I've procrastinated on switching to cygwin64, but I recently had to replace my laptop with a new Windows 10 machine, and figured I might as well install cygwin64. Everything went well until I discovered rxvt is not available in 64-bit. I found this thread (https://cygwin.com/ml/cygwin/2013-09/msg00016.html) from 9/2013 in the archives, but there doesn't seem to have been any resolution. Is there any plan to port rxvt to cygwin64? If not, does anyone have any hints so I can try it myself (I have 35 years of system software development experience, but I never worked on any cygwin software)? thanks, Peter -- 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: rxvt for cygwin64?
On 24/12/2015 09:12, qrasmfu...@snkmail.com wrote: I've been using cygwin's rxvt (without X) for years, and prefer it to mintty both because I use rxvt on all my linux machines and because I've never liked putty. Despite most (but not all) of my Windows machines running 64-but windows7, I've procrastinated on switching to cygwin64, but I recently had to replace my laptop with a new Windows 10 machine, and figured I might as well install cygwin64. Everything went well until I discovered rxvt is not available in 64-bit. I found this thread (https://cygwin.com/ml/cygwin/2013-09/msg00016.html) from 9/2013 in the archives, but there doesn't seem to have been any resolution. Is there any plan to port rxvt to cygwin64? no plan. rxvt is dead upstream, and rxvt without X is a hell and without a maintainer by long time mintty is a much better solution and with an active maintainer If not, does anyone have any hints so I can try it myself (I have 35 years of system software development experience, but I never worked on any cygwin software)? thanks, Peter Regards Marco -- 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
Default locale for Russian/Russia should be ru_RU.CP1251
Hi,
I'm running Cygwin 2.2.0 on an English Windows 8.1 box:
> CYGWIN_NT-6.3 UNIT-725 2.2.0(0.289/5/3) 2015-08-03 12:51 x86_64 Cygwin
Windows regional settings are set to Russian/Russia.
In the absence of any settings in bashrc/bash_profile, `locale` command
outputs the following:
> LANG=ru_RU
> LC_CTYPE="ru_RU"
> LC_NUMERIC="ru_RU"
> LC_TIME="ru_RU"
> LC_COLLATE="ru_RU"
> LC_MONETARY="ru_RU"
> LC_MESSAGES="ru_RU"
> LC_ALL=
This is perfectly fine, except that "no charset" in the locale output
means "ISO charset", which is ISO-8859-5 for Russian/Russia and has
never been used (historically, DOS used CP866, Windows used CP1251 ANSI
codepage, and various Unices sticked to KOI8-R before the rise of
Unicode era).
The above is consistent with locale charmap output, which is again
ISO-8859-5.
Short C example also confirms ISO-8859-5 is used:
> #include
>
> #include
> #include
>
> int main() {
> const char *locale = setlocale(LC_ALL, "");
> const char *codeset = nl_langinfo(CODESET);
> printf("locale: %s\n", locale);
> printf("codeset: %s\n", codeset);
>
> return 0;
> }
outputs
> locale: ru_RU/ru_RU/ru_RU/ru_RU/ru_RU/C
> codeset: ISO-8859-5
Cygwin docs state that
> Starting with Cygwin 1.7.2, the default character set is determined by the
> default Windows ANSI codepage for this language and territory.
which is not true in my case (Windows ANSI codepage for Cyrillic is
CP1251, not ISO-8859-5!). Surprisingly, for Belarusian (a.k.a
Belorussian, Eastern Slavic language very close to Russian) "be_BY"
locale the default charset is indeed CP1251 which is in accordance with
both the documentation and common sense.
Additionally, in `strace locale -u` output, I see multiple
> __get_lcid_from_locale: LCID=0x0419
lines.
"0x0419" corresponds to Russian/Russia (see
).
Despite that, $(locale -u) returns "en_GB", despite all regional
settings are set to Russian/Russia. I believe this is not correct,
either, and needs to be fixed.
Regards,
Andrey.
smime.p7s
Description: S/MIME Cryptographic Signature
