Re: CYGWIN_NT-6.1-WOW64: Unable to install rubies with rvm
Hi, Jon, I am using cygwin-1.7 on XP Professinal SP 3 and I do not use rvm, so things may be a little bit different from yours. But here are some information I know about ruby on cygwin. On 2010/11/17 3:11, Jon Seidel CMC wrote: Version 1.8.7 installation attempt [2010-11-16 09:37:58] make eval.c:211: error: conflicting types for '_longjmp' /usr/include/machine/setjmp.h:335: error: previous declaration of '_longjmp' was here eval.c:211: error: conflicting types for '_longjmp' /usr/include/machine/setjmp.h:335: error: previous declaration of '_longjmp' was here As Csaba pointed out, _longjmp is among the things that changed between cygwin 1.5 and 1.7. So ruby 1.8 cannot be built on cygwin-1.7 . This _longjmp problem was fixed in ruby subversion trunk revision 23317, and the fix was backported to then-current ruby_1_9_1 branch. So now, all ruby 1.9.x can be built on cygwin-1.7 . But so far, nobody has made the effort to do the porting and testing of ruby 1.8.x on cygwin-1.7, probably because no more active development is happening for ruby 1.8. ruby 1.8 is fading out. So what I recommend is 1. Get official ruby-1.8.7-p72-2 from cygwin.com . It was built for cygwin-1.5 and is outdated, but it can be used to help build ruby-1.9.x . 2. Then build ruby 1.9.2 (or trunk). 3. If ruby 1.9.2 is built successfully, uninstall ruby-1.8.7-p72-2 . A few weeks ago, I successfully built ruby 1.9.2p35 (2010-11-02 revision 29665) [i386-cygwin] ruby 1.9.3dev (2010-11-02 trunk 29669) [i386-cygwin] from ruby_1_9_2 branch and trunk, respectively. They both showed several test failures (as always on cygwin), but are good enough for my daily usage. So, at least these revisions are known to work on cygwin-1.7. (Actually, most revisions that I have tried worked. The codes seem to be very well maintained.) I hope these information helps you build ruby-1.9 on CYGWIN_NT-6.1-WOW64 . -- neomjp -- Get the new Internet Explorer 8 optimized for Yahoo! JAPAN http://pr.mail.yahoo.co.jp/ie8/ -- 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: gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app.
On 27 Aug 2010 19:33:36 +0100, Andy Koppe wrote: It will be synced with the POSIX working directory again, except when the path is too long or it's a virtual directory such as /proc. Thank you for summarizing the thread. I tried using the snapshot cygwin1-20100829.dll.bz2 and confirmed that gitk works okay again. One thing to note. I said in the previous mail that gitk unusable in cygwin-1.7.6-1, but after more testing, I found I was wrong in saying that. The correct description of the problem in cygwin-1.7.6-1 was gitk does work in a directory with only ascii characters in its path, but is unusable in a directory that contains a non-ascii character in its path. In the latter case, echo puts [pwd]|wish returned //?/PIPE . But I confirmed this was fixed and gitk works again in the snapshot cygwin1-20100829.dll.bz2 . I thank the developers for fixing this. -- neomjp -- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/ -- 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
gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app.
When I invoke gitk like this:
#
$ cygcheck -c cygwin git gitk tcltk
Cygwin Package Information
Package VersionStatus
cygwin 1.7.6-1OK
git 1.7.1-1OK
gitk 1.7.1-1OK
tcltk20080420-1 OK
$ ls -a
. .. .git
$ git rev-parse --git-dir
.git
$ gitk
#
I got the following error:
#
Cannot find a git repository here.
#
This error message is shown when a valid .git directory is not found.
#
$ sed -n 11441,11446p /usr/bin/gitk
# check that we can find a .git directory somewhere...
if {[catch {set gitdir [gitdir]}]} {
show_error {} . [mc Cannot find a git repository here.]
exit 1
}
#
But as the ls -a output above shows, I do have a .git directory. So this
means the procedure gitdir somehow failed to detect the .git directory.
The cause of this error comes down to this:
#
$ echo puts [pwd]|wish
//?/PIPE
#
/usr/bin/gitk is a tcl (wish) script, but tcltk-20080420-1 is a native
Win32 app. So in cygwin-1.7.6-1, the working directory of wish is set to
//?/PIPE. That is why the git command invoked from inside gitk failed
saying Cannot find a git repository here.
A temporary workaround is to use cygwin-1.7.5-1, but,
1. I see a long discussion about cygwin vs. win32 CWD is taking place in
cygwin-developer. What is win32 CWD going to be in cygwin in the future?
2. I understand that the reason to have tcltk-20080420-1 as a win32 app is
to have a graphical insight that does not depend on X Window. (Thread
Does anyone use insight on cygwin? in cygwin 2008-08.) But in the thread
gdb, insight, and tcltk in cygwin 2009-10, Charles Wilson discussed War
and Peace of an X-based package. Is anything moving recently in this vein?
--
neomjp
--
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/
--
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
git-1.7.0.4-2 put files in .../python2.5/site-packages/ .
Hi, After the hard work by Jason, Yaakov, Jari, and others to upgrade python from 2.5 to 2.6, I found my .../python2.5/site-packages/ was not empty yet. $ cygcheck -c git Cygwin Package Information Package VersionStatus git 1.7.0.4-2 OK $ cygcheck -l git |grep 2.5 /usr/lib/python2.5/site-packages/git_remote_helpers/git/git.py /usr/lib/python2.5/site-packages/git_remote_helpers ...snip... /usr/lib/python2.5/site-packages/git_remote_helpers/__init__.pyc /usr/lib/python2.5/site-packages/git_remote_helpers-0.1.0-py2.5.egg-info A rebuild with python2.6 will fix this, I suppose. -- neomjp -- 2010 FIFA World Cup News [Yahoo!Sports/sportsnavi] http://pr.mail.yahoo.co.jp/southafrica2010/ -- 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
luit package and pty
Hi, The recent xterm is configured with --enable-luit, but /usr/bin/luit is currently broken. $ cygcheck -f `which luit` luit-1.0.3-1 $ luit Couldn't allocate pty: No such file or directory The cause of this error and a possible fix is in http://sourceware.org/ml/cygwin/2009-04/msg00725.html Could you please consider incorporating this fix into the luit package? -- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
luit-1.0.3-1: Couldn't allocate pty: No such file or directory
$ cygcheck -c luit
Cygwin Package Information
Package VersionStatus
luit 1.0.3-1OK
$ /usr/bin/luit.exe
Couldn't allocate pty: No such file or directory
This error is caused by trying to opening a pseudo terminal in a BSD
way (instead of in a SVR4 or Unix-98 way). Here are the relevant parts
in sys.c:
#if (defined(__GLIBC__) \
(__GLIBC__ 2 || (__GLIBC__ == 2 __GLIBC_MINOR__ = 1))) || \
defined(SVR4)
#define HAVE_GRANTPT
#endif
...
int
allocatePty(int *pty_return, char **line_return)
{
char name[12], *line = NULL;
int pty = -1;
char *name1 = pqrstuvwxyzPQRST,
*name2 = 0123456789abcdefghijklmnopqrstuv;
...
#ifdef HAVE_GRANTPT
pty = open(/dev/ptmx, O_RDWR);
.
#endif /* HAVE_GRANTPT */
strcpy(name, /dev/pty??);
for(p1 = name1; *p1; p1++) {
name[8] = *p1;
for(p2 = name2; *p2; p2++) {
name[9] = *p2;
pty = open(name, O_RDWR);
In cygwin, the absense of __GLIBC__ or SVR4 causes HAVE_GRANTPT to be
undefined, and so the codes to use SVR4 (or Unix-98) pseudo terminals
are not enabled.
A simple fix is to add || defined(__CYGWIN__),
but the recent master of luit has a better fix. It replaced #if
(defined(__GLIBC__) ... with a real configure test for grantpt.
http://cgit.freedesktop.org/xorg/app/luit/commit/?h=4823838f77ab03cccd07860fdf8002bc577e0f04
--
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [1.7] Support for CJK Character Sets
. CP50222 used another escape sequence. It uses the combination of RFC1468-defined ESC(J and SHIFT-OUT(0x0e)/SHIFT-IN(0x0f). I do not know of any utility to simulate it, but for example, create a file with a name of a sequence of 'KATAKANA LETTER A' (U+30A2) and 'HALFWIDTH KATAKANA LETTER A' (U+FF71), chcp 50222, dir to some file, and od, I get, 1b 24 42 25 22 1b 28 4a 0e 31 1b 28 42 esc $ B %esc ( J so 1 esc ( B Note that 'KATAKANA LETTER A' part is the same as CP50220 (1b 24 42 25 22), but the highest bit of 0xb1 for 'HALFWIDTH KATAKANA LETTER A' is dropped to be 0x31, and it is prepended by esc ( J and so(0x0e). (si(0x0f) is not used here because it is at the end.) In contrast to CP50220, CP50221 and CP50222 supports conversion of halfwidth Katakana's to and from UTF-16 is supported for . But these are not valid ISO-2022-JP, are not guaranteed to work with all applications. For example, iconv cannot handle them correctly. CP50220 produces valid ISO-2022-JP, but as I wrote before, two files with halfwidth and double byte Kana's cannot be distinguished. Conclusion: users should be careful when using CP50220-50222. They should stick to standard ISO-2022-JP. No, no. I implemented the full three-byte variation as it is, for instance, implemented in glibc as well. Cygwin converts the CP 20932 doublebyte sequences for JIS X 0212 into Unix compatible triplebyte sequences and vice versa. So Cygwin applications see a Unix-like eucJP implementation, not a CP 20932 implementation. Thanks, that is more than I expected. -- neomjp -- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [1.7] Support for CJK Character Sets
On 2009/04/06 20:04, Corinna Vinschen wrote: After some long mulling over this problem, I gave up on supporting JIS. So, I removed JIS support from Cygwin again. Given that SJIS and eucJP are both available, this shoudn't pose a big problem for Japanese users. Ok, I understand. I was starting to write a mail about the differences among CP50220-50222, but I will quit it. This is fixed now in CVS. The fact that eucJP knows triplebyte sequences but the Windows eucJP codepage 20932 does not (converting these widechars to incompatible doublebyte sequences instead) was not really helpful but as far as I can test it, it appears to work now. Thanks for the fix. If the double byte eucJP works, I think it is ok. Actually, there are several variants of eucJP. Microsoft made some modifications to the original to create codepage 20932 and 51932. Triple byte one is another extension. If the common parts are supported, I think it is enough. The common parts are http://unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/JIS0201.TXT (Add 0x8e00 to change Column #1 into EUC-JP) http://unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/JIS0208.TXT (Add 0x8080 to change Column #2 into EUC-JP) These two are the common parts. If http://unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/JIS0212.TXT (Add 0x8f8080 to change Column #1 into EUC-JP, that is, triple bytes.) is also supported, it will be nice (This JIS X 0212 specifies Kanji's used less frequently than JIS X 0208). But JIS X 0212 is not always supported in all implementations. (According to http://ja.wikipedia.org/wiki/EUC-JP, triple byte is not supported in CP51932.) Please note that eucJP does not work by default on Windows XP and earlier OSes! At least not on the so-called western languages installations, US, French, Italian, whatever. The reason is that the So, if you're running XP or earlier, unless you installed CP 20932, eucJP support in Cygwin is as broken as in the underlying Windows. Then probably we are the exception to have it installed by default. C:\chcp 20932 Active code page: 20932 C:\ Thanks for this report, SJIS and eucJP supports are good progress. I will be looking forward to cygwin-1.7.0-46. -- neomjp -- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[1.7] Support for CJK Character Sets
On 2009/04/02 22:46, Corinna Vinschen wrote:
Btw., it's really not tricky to create a filename with special
characters:
I used this Corinna's tiny program
(http://sourceware.org/ml/cygwin/2009-04/msg00053.html )
to create a file with a name containing a CJK character and tested
how setting LANG works.
I changed 0x20ac to 0x4e00 (CJK Ideograph, First). This is one of the
characters used in all three languages. It is 0xe4 0xb8 0x80 in
hexadecimal UTF-8. So, without setting LANG, the file name should look
like qq\016\344\270\200. (Note that the \016 is ASCII SO,
which shows that cygwin could not convert the next character to the
character set).
I checked how the look of the file name changes by setting LANG to each
character set. A list of supported character sets is found in
http://cygwin.com/1.7/cygwin-ug-net/setup-locale.html .
The result (see below) was that the filename was correctly converted
to UTF-8 or SJIS or GBK or Big5 or eucKR. They correctly matched the
name converted using iconv.
But it failed for JIS/ISO-2022-JP and eucJP. (It was represented as
ASCII SO(0x0e)/UTF-8 sequence).
What is going wrong here? What makes the file name conversion from
UTF-16 to these character sets to fail? Or, what am I doing wrong?
Any hints?
--
neomjp
for lang in UTF-8 SJIS GBK Big5 ISO-2022-JP eucJP eucKR ; do
export LANG=en_US.${lang};
echo; echo LANG=${LANG};
ls q* | od -t x1 -t a;
export LANG=en_US.UTF-8;
echo This must be identical to:
ls q* | iconv -f UTF-8 -t ${lang} | od -t x1 -t a;
unset LANG ;
done;
LANG=en_US.UTF-8
000 71 71 e4 b8 80 0a
q q d 8 nul nl
006
This must be identical to:
000 71 71 e4 b8 80 0a
q q d 8 nul nl
006
LANG=en_US.SJIS
000 71 71 88 ea 0a
q q bs j nl
005
This must be identical to:
000 71 71 88 ea 0a
q q bs j nl
005
LANG=en_US.GBK
000 71 71 d2 bb 0a
q q R ; nl
005
This must be identical to:
000 71 71 d2 bb 0a
q q R ; nl
005
LANG=en_US.Big5
000 71 71 a4 40 0a
q q $ @ nl
005
This must be identical to:
000 71 71 a4 40 0a
q q $ @ nl
005
LANG=en_US.ISO-2022-JP
000 71 71 0e e4 b8 80 0a
q q so d 8 nul nl
007
This must be identical to:
000 71 71 1b 24 42 30 6c 1b 28 42 0a
q q esc $ B 0 l esc ( B nl
013
LANG=en_US.eucJP
000 71 71 0e e4 b8 80 0a
q q so d 8 nul nl
007
This must be identical to:
000 71 71 b0 ec 0a
q q 0 l nl
005
LANG=en_US.eucKR
000 71 71 ec e9 0a
q q l i nl
005
This must be identical to:
000 71 71 ec e9 0a
q q l i nl
005
--
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Updated: xterm-238-1
On 2009/02/20 20:24, Thomas Wolff wrote: please add the following configure options to the xterm package: --enable-wide-chars to provide a UTF-8 environment for applications that need to use it --enable-256-color Both options are already enabled in xterm-238-1. (Try installing the xterm-238-1 source package and see /usr/src/xterm-238-1.cygport .) For more information on how to enable utf8 resource, see http://sourceware.org/ml/cygwin-xfree/2008-12/msg00079.html -- neomjp -- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Bug in startXwin.bat
Larry Hall (Cygwin X) wrote: Linda Walsh wrote: Larry Hall (Cygwin X) wrote: Linda Walsh wrote: Larry Hall (Cygwin X) wrote: Linda Walsh wrote: The startxwin.sh script works, but startxwin.bat does not work if your Cygwin installation isn't in the default location. As Larry and others have pointed out, this is because cmd.exe batch files cannot know where Cygwin is installed. So startxwin.bat hardcodes the default installation location of Cygwin in it (SET CYGWIN_ROOT=\cygwin). Linda and http://sourceware.org/ml/cygwin-xfree/2009-01/msg00173.html http://sourceware.org/ml/cygwin-xfree/2009-02/msg00052.html they all belong to the case where 1. s/he installed Cygwin in a non-default location, 2. read Cygwin/X FAQ 3.3. I can't find startxwin.bat to start the X server, and 3. tried the Start Menu item Cygwin-X/XWin Server. Here are two possible solutions for this case, each with a patch. The first one sets CYGWIN_ROOT to the parent of /bin where this startxwin.bat is installed. It uses cmd.exe batch parameter syntax to get the path value. The documentation for this cryptic parameter syntax can be found in http://technet.microsoft.com/en-us/library/cc755880.aspx http://www.computerhope.com/sethlp.htm REMarks are just remarks and can be deleted if necessary. The second one avoids using startxwin.bat at all. It invokes /usr/bin/run.exe to run /bin/bash to run /usr/bin/startxwin.sh. Possibly, /usr/bin/startx can be used instead of startxwin.sh, but I picked startxwin.sh because it contains the code to delete /tmp/.X11-unix/X0. This solution is better than the first in that no cmd.exe batch file is used, but is worse in that two black cmd.exe windows flash and disappear before XWin starts up. These two are not the ideal solution, but at least they work for the above case. I hope these patches help and get thoughtfully considered. -- neomjp diff -us /usr/bin/startxwin.bat /usr/bin/startxwin.bat.new.bat --- /usr/bin/startxwin.bat 2009-01-19 15:43:42.00100 +0900 +++ /usr/bin/startxwin.bat.new.bat 2009-02-14 05:52:03.84375 +0900 @@ -3,21 +3,24 @@ REM -REM The path in the CYGWIN_ROOT environment variable assignment assume -REM that Cygwin is installed in a directory called 'cygwin' in the root -REM directory of the current drive. You will only need to modify -REM CYGWIN_ROOT if you have installed Cygwin in another directory. For -REM example, if you installed Cygwin in \foo\bar\baz\cygwin, you will need -REM to change \cygwin to \foo\bar\baz\cygwin. -REM -REM This batch file will almost always be run from the same drive (and -REM directory) as the drive that contains Cygwin/X, therefore you will -REM not need to add a drive letter to CYGWIN_ROOT. For example, you do -REM not need to change \cygwin to c:\cygwin if you are running this -REM batch file from the C drive. -REM +REM The following assignment to the CYGWIN_ROOT environment variable +REM assumes that this batch file is installed in /bin . (In +REM default Cygwin installation, this /bin is also mounted as +REM /usr/bin .) CYGWIN_ROOT is first set to the Windows format +REM drive letter (~d) and parent path (p) of this batch file (%0). +REM Then, the last four characters (\bin) are removed. +REM + +SET CYGWIN_ROOT=%~dp0 +SET CYGWIN_ROOT=%CYGWIN_ROOT:~0,-4% + +REM +REM If you move/copy this batch file to another place, you need to +REM set CYGWIN_ROOT explicitly to the Windows format path of the +REM directory where Cygwin is installed, as in an example below. +REM +REM SET CYGWIN_ROOT=C\:cygwin -SET CYGWIN_ROOT=\cygwin SET RUN=%CYGWIN_ROOT%\bin\run -p /usr/bin SET PATH=.;%CYGWIN_ROOT%\bin;%PATH% diff -u /etc/postinstall/xinit.sh /etc/postinstall/xinit.sh.new --- /etc/postinstall/xinit.sh 2009-01-19 15:43:42.00100 +0900 +++ /etc/postinstall/xinit.sh.new 2009-02-14 06:04:24.140625000 +0900 @@ -1,2 +1,2 @@ /usr/bin/mkdir -p $(/usr/bin/cygpath -AP)/Cygwin-X -/usr/bin/mkshortcut -AP -i /usr/bin/XWin.exe -n Cygwin-X/XWin Server -w -a /usr/bin/startxwin.bat /usr/bin/run.exe +/usr/bin/mkshortcut -AP -i /usr/bin/XWin.exe -n Cygwin-X/XWin Server -w /usr/bin -a /bin/bash -l -c /usr/bin/startxwin.sh /usr/bin/run.exe -- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xterm-237-2 still has no UTF-8 support
On 2008/12/10 0:39, Yongwei Wu wrote: 1. xterm +lc -u8 I got these messages: Warning: Cannot convert string -adobe-helvetica-bold-r-normal--*-120-*-*-*-*-iso8859-* to type FontStruct Warning: Cannot convert string nil2 to type FontStruct These are the default fonts specified in /etc/X11/app-defaults/XTerm. -adobe-helvetica-... are provided by font-adobe-dpi100 and font-adobe-dpi75, and nil2 is provided by font-misc-misc. Do you have these fonts installed? What does cygcheck -c | grep font say? If these warnings persist, then you may have something wrong or some non-default settings about fonts. 1. Re-run (as in /etc/postinstall/fontconfig.sh) /usr/bin/fc-cache -r 2. Do you have any files in ls -l ~/.[xX]* 3. Did you modify any files in grep -ril font /etc/X11/|xargs md5sum (On my machine, it says: dd942bff017ee9cfc2bb97bbdd7378b6 */etc/X11/app-defaults/KOI8RXTerm 952670ddfbb90d0a7c36e87e7a796595 */etc/X11/app-defaults/UXTerm 3229b9daa5116a184ebe78949c8794f9 */etc/X11/app-defaults/XTerm I believe these are the default.) 4. How do you start up XWin (startx, starxwin.sh, startxwin.bat, etc.) and xterm? Does the file contain anything about fonts? -- neomjp -- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xterm-237-2 still has no UTF-8 support
On 4:59, Yongwei Wu wrote: The recent xterm-237-2 still does not have the Unicode support It does. But according to xterm-237-2.cygport, it is configured with --enable-luit --enable-wide-chars. man xterm(1) says in the description of -u8, This option and the utf8 resource are overridden by the ‐lc and ‐en options and locale resource. That is, if xterm has been compiled to support luit, and the locale resource is not ‘‘false’’ this option is ignored. So, -u8 will be ignored without proper options. Try either: 1. xterm +lc -u8 2. xterm -en UTF-8 3. or use cygwin-1.7 with proper locale settings. Start bash and say, perl -we 'binmode(STDOUT, :utf8); print(pack(U*, 12371, 12435, 12395, 12385, 12399, 32, 50504, 45397, 54616, 49464, 50836, 63, 32, 20320, 22909));' This should print hello in Japanese, Korean, and Chinese. -- neomjp -- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: cygport/rsync problem
I wrote this mail as a reply to http://sourceware.org/ml/cygwin-apps/2008-10/msg00075.html but let me post it here because I am not a package maintainer and am not a subscriber to cygwin-apps. On 2008/10/26 21:42, Steffen Sledz wrote: rsync: Failed to dup/close: Socket operation on non-socket (108) rsync error: error in IPC code (code 14) at /home/lapo/packaging/rsync-3.0.4-1/src/rsync-3.0.4/pipe.c(147) [receiver=3.0.4] rsync: read error: Connection reset by peer (104) rsync error: error in IPC code (code 14) at /home/lapo/packaging/rsync-3.0.4-1/src/rsync-3.0.4/io.c(791) [sender=3.0.4] This is probably the same error as the one that I had when using rsync in cygwin-1.7. It is probably caused by some firewall or anti-virus software blocking the operation of rsync. In my case, the culprit was NOD32. When I ran rsync in gdb, $ mkdir somedir $ touch somedir/somefile $ gdb --args /usr/bin/rsync -a somedir/ anotherdir GNU gdb 6.8.0.20080328-cvs (cygwin-special) . (no debugging symbols found) (gdb) run Starting program: /usr/bin/rsync -a somedir/ anotherdir . (no debugging symbols found) warning: NOD32 protected [MSAFD Tcpip [TCP/IP]] warning: NOD32 protected [MSAFD Tcpip [UDP/IP]] warning: NOD32 protected [MSAFD Tcpip [RAW/IP]] warning: NOD32 protected [RSVP UDP Service Provider] warning: NOD32 protected [RSVP TCP Service Provider] (no debugging symbols found) (no debugging symbols found) ---Type return to continue, or q return to quit--- (no debugging symbols found) [New thread 1508.0x720] [New thread 1508.0xeb0] [New thread 1508.0x54c] rsync: Failed to dup/close: Socket operation on non-socket (108) rsync error: error in IPC code (code 14) at /home/lapo/packaging/rsync-3.0.4-1/src/rsync-3.0.4/pipe.c(147) [receiver=3.0.4] I have had no problems with rsync in cygwin-1.5 and NOD32. There must be some changes in the implementation of socket/IPC/pipe between cygwin-1.5 and -1.7, which NOD32 does not like. I did not track it down further because this is a problem of NOD32 and because the workaround was simple: add rsync to the exception list of NOD32. -- Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more! http://pr.mail.yahoo.co.jp/mlb/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: xterm(229-1) does not accept -u8
On 2007/08/23 19:56, Thomas Dickey wrote: yes (but even if it's built to support UTF-8, cygwin has very limited locale support - no UTF-8, except as noted a while back, applications that have built-in locale support such as mined will work). Thank you for confirming this, Thomas. I read an debian-x thread, Bug#341686: xterm cannot be started in utf-8 mode by default http://lists.debian.org/debian-x/2005/12/msg00044.html in which you discussed this xterm locale issue, xterm -xrm '*locale:false' -u8, and mined. I understand that cygwin has limited support for locale, but even so, many small utilities in cygwin packages can work with UTF-8, such as sed, awk, perl, ruby, grep, cat, head, tail, less(with LESSCHARSET=utf-8) and so on. These are the things used very often inside xterm, and that is when -u8 is needed. I will be glad if UTF-8 support is turned back on again, maybe in future updates. -- neomjp -- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
xterm(229-1) does not accept -u8
The newly uploaded xterm(229-1) prematurely exits when the command line option -u8 is given, saying: - $ xterm -u8 [1] 2932 xterm: bad command line option -u8 usage: xterm [... .. Type xterm -help for a full description. - -u8 is not listed in the output of xterm -help, either. (-u8 is surely described in man page.) -u8 used to work in xterm(202-1) and was also listed in xterm -help. Similar problem was reported before for xterm-185-2, and the cause was that --enable-wide-chars was not used at the configuration step. (http://cygwin.com/ml/cygwin-xfree/2004-03/msg00616.html) I wonder if it is also the case this time. -- neomjp -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
