wamp cygwin php. Files with acl, setfacl, issue
I'm running wamp/cygwin as a testing environment, and php doesn't want to recognise any files I create under cygwin (eg vim/touch etc) as they don't have the additional permissions (no + at the end of an ls -l command) . For example, a php 'is_file()' returns false on a file that most certainly exists. Figuring out what was going on was source of much headache. I'm sure I am not the first person to have this problem, but I'm having trouble finding info, I've been reading about extended file permissions and setfacl etc, but I don't know how to set it up so I don't have to manually setfacl each file I create in cygwin? Help appreciated, thanks. -- 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
Mark J. Reed wrote: >> Warning: Cannot convert string >> "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-iso8859-*" to type >> FontStruct >> Warning: Cannot convert string "nil2" to type FontStruct >> >> And non-ASCII characters become either spaces or question marks. I >> verified that I can copy the correct characters, but they do not >> appear. > > If you can copy them and they appear properly when you paste, that > would seem to imply that the xterm is correctly handling the Unicode > characters. It's just that the associated glyphs are not present in > the font you're using. Good reasoning. I think you are right. Then who is to blame? :-) Another phenomenon I have observed: one cannot change the fonts in the VT Fonts menu. Something is still wrong here, but I am not sure whether it is in xterm or the rest of the XWindow system. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ -- 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 line wrapping
Thomas Dickey wrote on Wednesday, December 10, 2008 1:31 AM:: > On Tue, Dec 09, 2008 at 10:57:53AM -0500, Gustavo Seabra wrote: >> Hi All, >> >> I wonder if anyone else sees this. When I open an xterm, it all works >> fine with the default dimensions. But if I resize the terminal, line >> wrapping stops working until I return to the initial size. This was >> present in the old xterm, and persists after upgrading to the new >> one. > > that sounds like the "feature" in bash which makes it not pass on the > SIGWINCH signal, depending on bash's settings. (I should add it to > my ncurses faq, since the bash maintainer doesn't answer this > question) > >> Interestingly, if I have a file opened in vi when resizing, vi works >> quite well and wraps the lines correctly according to the terminal >> size. But when I get out of vi I get the same problems back :-( > > vi is probably doing the ioctl to check on the screensize... Try the command "shopt -s checkwinsize" in bash. This causes bash to check the terminal size after every command and adjusts $LINES and $COLUMNS to the correct values. If that works, add it to your .bashrc Phil -- This email has been scanned by Ascribe PLC using Microsoft Antigen for Exchange. -- 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 line wrapping
On Tue, Dec 09, 2008 at 10:57:53AM -0500, Gustavo Seabra wrote: > Hi All, > > I wonder if anyone else sees this. When I open an xterm, it all works > fine with the default dimensions. But if I resize the terminal, line > wrapping stops working until I return to the initial size. This was > present in the old xterm, and persists after upgrading to the new one. that sounds like the "feature" in bash which makes it not pass on the SIGWINCH signal, depending on bash's settings. (I should add it to my ncurses faq, since the bash maintainer doesn't answer this question) > Interestingly, if I have a file opened in vi when resizing, vi works > quite well and wraps the lines correctly according to the terminal > size. But when I get out of vi I get the same problems back :-( vi is probably doing the ioctl to check on the screensize... -- Thomas E. Dickey <[EMAIL PROTECTED]> http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
RE: OpenGL-1.1.0 compile problem in cygwin-1.7
Hi Andre,
This:
gluTessCallback(tobj, (GLenum)GLU_BEGIN, glBegin);
gluTessCallback(tobj, (GLenum)GLU_END, glEnd);
gluTessCallback(tobj, (GLenum)GLU_VERTEX, glVertex2fv);
Would give me these errors:
x.c++: In function `void test()':
x.c++:7: error: invalid conversion from `void (*)(GLenum)' to `void (*)()'
x.c++:7: error: initializing argument 3 of `void
gluTessCallback(GLUtesselator*, GLenum, void (*)())'
x.c++:9: error: invalid conversion from `void (*)(const GLfloat*)' to `void
(*)()'
x.c++:9: error: initializing argument 3 of `void
gluTessCallback(GLUtesselator*, GLenum, void (*)())'
But the below fixes the problem:
gluTessCallback(tobj, (GLenum)GLU_BEGIN, (_GLUfuncptr)glBegin);
gluTessCallback(tobj, (GLenum)GLU_END, glEnd);
gluTessCallback(tobj, (GLenum)GLU_VERTEX, (_GLUfuncptr)glVertex2fv);
Thanks Andre,
Linh
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of André Bleau
Sent: Tuesday, December 09, 2008 5:38 AM
To: cygwin-xfree@cygwin.com
Subject: RE: OpenGL-1.1.0 compile problem in cygwin-1.7
"Phan, Linh H" wrote:
>
> Hi Brian,
>
> Can you show me how I can fix the cast? I tried this:
>
> #include
> #include
> void test (void)
> {
> GLUtesselator *tobj = (GLUtesselator *)gluNewTess();
> gluTessCallback(tobj, (GLenum)GLU_BEGIN, (void (*)())glBegin);
> gluTessCallback(tobj, (GLenum)GLU_END, glEnd);
> gluTessCallback(tobj, (GLenum)GLU_VERTEX, (void (*)())glVertex2fv);
> }
>
> And that fixed it for glEnd, but I don't know how to fix the glBegin and
> glVertex2fv.
> This is not my code; it's part of the SGI OpenInventor library.
>
> Thank you,
>
> Linh
>
Hi Linh,
Did you try:
#include
#include
void test (void)
{
GLUtesselator *tobj = gluNewTess();
gluTessCallback(tobj, (GLenum)GLU_BEGIN, glBegin);
gluTessCallback(tobj, (GLenum)GLU_END, glEnd);
gluTessCallback(tobj, (GLenum)GLU_VERTEX, glVertex2fv);
}
Anyway, glu.h shows that the prototype for gluTessCallback is:
GLAPI void APIENTRY gluTessCallback (GLUtesselator* tess, GLenum which,
_GLUfuncptr CallBackFunc);
so (_GLUfuncptr) is the obvious cast, no?
- André Bleau, Cygwin's volunteer OpenGL package maintainer.
Please direct any question or comment about the OpenGL package to cygwin at
cygwin dot com
_
--
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/
--
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: OpenGL-1.1.0 compile problem in cygwin-1.7
That worked. Thanks Brian, Linh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Dessent Sent: Tuesday, December 09, 2008 7:07 AM To: cygwin-xfree@cygwin.com Subject: Re: OpenGL-1.1.0 compile problem in cygwin-1.7 "Phan, Linh H" wrote: > gluTessCallback(tobj, (GLenum)GLU_BEGIN, (void (*)())glBegin); > gluTessCallback(tobj, (GLenum)GLU_END, glEnd); > gluTessCallback(tobj, (GLenum)GLU_VERTEX, (void (*)())glVertex2fv); > } > > And that fixed it for glEnd, but I don't know how to fix the glBegin and > glVertex2fv. This is not my code; it's part of the SGI OpenInventor library. You can use a typedef to make life a little easier. There's already one in glu.h that you can reuse (although it looks like it's not meant to be part of the public interface so it might not be the best idea to rely on it): typedef void (APIENTRY *_GLUfuncptr)(); Then the cast becomes just "(_GLUfuncptr)whatever". Brian -- 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/ -- 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: OpenGL-1.1.0 link problem (glXMakeCurrent undefined symbols)
Hi Andre, > Either you follow the Win32 road ... > Or you follow the X server road. I have been following the X server road (libGL-devel, libGL1, libGLU-devel, libGLU1 and that has been working fine for me) but I guess those are Mesa libraries which does not benefit from hardware acceleration, so when I read your opengl announcement: > These programs can display through the native Windows interface > (Win32) and benefit from hardware and driver acceleration. I wanted the benefit from hardware acceleration, even though I don't care for the Windows interface. Is it possible for me to not use the Windows interface but benefit from the hardware acceleration? Thank you Andre, Linh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of André Bleau Sent: Tuesday, December 09, 2008 6:00 AM To: cygwin-xfree@cygwin.com Subject: Re: OpenGL-1.1.0 link problem (glXMakeCurrent undefined symbols) "Phan, Linh H" wrote: > Hi, Hi Linh, > I'm trying to port OpenInventor code and using the new opengl-1.1.0 and I > am getting > undefined _glXMakeCurrent symbols: > /usr/bin/CC -g Main.o ClassDef.o Man.o Reader.o Writer.o BuildIssues.o > -lInventor -lstdc++ > -L/usr/X11R6/lib -L/usr/local/lib -limage -ljpeg -liconv -lFL -lfreetype > -lglu32 -lopengl32 -lXm -lXt -lXext -lXi -lX11 -lm -o ivman > /usr/local/lib/libInventor.a(So.o): In function > `_ZN19SoOffscreenRendererD2Ev': > /usr/local/src/inventor2/lib/database/src/so/SoOffscreenRenderer.c++:173: > undefined reference to > `_glXDestroyGLXPixmap' > /usr/local/src/inventor2/lib/database/src/so/SoOffscreenRenderer.c++:174: > undefined reference to > `_glXDestroyContext' > /usr/local/src/inventor2/lib/database/src/so/SoOffscreenRenderer.c++:755: > undefined reference to > `_glXMakeCurrent' > ... > I could see it in: > [EMAIL PROTECTED] ...inventor2/lib]$ nm /usr/X11R6/lib/libGL-1.dll.a |grep > glXMakeCurrent > I __imp__glXMakeCurrentReadSGI > T _glXMakeCurrentReadSGI > I __imp__glXMakeCurrent > T _glXMakeCurrent > What library in the new opengl-1.1.0 can I used to fix this problem? > Thank you, > Linh > Yeurk! The problem here is that you are trying to mix to incompatible things: 1- libraries from the w32api package (-lglu32 -lopengl32) which are about displaying openGL graphics directly through a native Windows interface (Win32) without any X server; 2- some other librairies (-lX...) that are about displaying through an X server. Than cannot work. You must make up your mind: Either you follow the Win32 road and you move your discussion to cygwin at cygwin dot com (as Yaakov suggested). Or you follow the X server road. As OpenInventor is some SGI thing, it is probably the best choice. In that case, you should update all your X11-related packages (-L/usr/X11R6/lib is related to the old version). In particular, you will need the following packages: libGL-devel, libGL1, libGLU-devel, libGLU1, which are about displaying openGL graphics through an X server. In that case, keep the discussion at cygwin-xfree at cygwin dot com. - André Bleau, Cygwin's volunteer OpenGL package maintainer. Please direct any question or comment about the OpenGL package to cygwin at cygwin dot com _ -- 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/ -- 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: Keyboard map screwed up after launching xemacs
- Original Message - From: "Jon TURNEY" <[EMAIL PROTECTED]> To: Sent: Tuesday, December 09, 2008 5:29 PM Subject: Re: Keyboard map screwed up after launching xemacs > Jon TURNEY wrote: > > Forgive my ignorance about german keyboard usage, but is the tilde > > character used in some kind of composition sequence which isn't working > > anymore? Or do you just want to type lots of tildes? (In case that it went down the drain: One is enough,: ~ = -> $HOME :) > Ok, it seems I can reproduce this by telling Windows I have a german keyboard > (although starting the X server with '-xkblayout de' doesn't seem to be > sufficient, which is somewhat mysterious) and it only affects the xemacs window. Great! Thanks for still bearing with me. > A workaround seems to be to do 'setxkbmap de' before starting xemacs. > > This and other reported problems make me thing something not quite right about > the way we are initializing XKB for an autodetected keyboard layout > (probably related to MPX changes in the X server), which needs more > investigation I fully agree. -Andreas -- 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: Keyboard map screwed up after launching xemacs
Jon TURNEY wrote: Andreas Eibach wrote: Hi, when I have X running and start off (latest) xemacs & from the command line, my German keyboard is non-existing. WTF? Even the important tilde character can't be typed anymore. Not only until I quit xemacs, my keymap in xterm works again as expected. Are you saying the the keymap for all X windows is changed while xemacs is running? Or does it only affect the Xemacs window? Forgive my ignorance about german keyboard usage, but is the tilde character used in some kind of composition sequence which isn't working anymore? Or do you just want to type lots of tildes? Ok, it seems I can reproduce this by telling Windows I have a german keyboard (although starting the X server with '-xkblayout de' doesn't seem to be sufficient, which is somewhat mysterious) and it only affects the xemacs window. Andreas Eibach wrote: > Anyway to fix this? A workaround seems to be to do 'setxkbmap de' before starting xemacs. This and other reported problems make me thing something not quite right about the way we are initializing XKB for an autodetected keyboard layout (probably related to MPX changes in the X server), which needs more investigation -- 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 Tue, Dec 9, 2008 at 10:39 AM, Yongwei Wu wrote: > 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 > > And non-ASCII characters become either spaces or question marks. I > verified that I can copy the correct characters, but they do not > appear. If you can copy them and they appear properly when you paste, that would seem to imply that the xterm is correctly handling the Unicode characters. It's just that the associated glyphs are not present in the font you're using. -- 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 line wrapping
Hi All, I wonder if anyone else sees this. When I open an xterm, it all works fine with the default dimensions. But if I resize the terminal, line wrapping stops working until I return to the initial size. This was present in the old xterm, and persists after upgrading to the new one. Interestingly, if I have a file opened in vi when resizing, vi works quite well and wraps the lines correctly according to the terminal size. But when I get out of vi I get the same problems back :-( Thanks, Gustavo. -- 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
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
And non-ASCII characters become either spaces or question marks. I
verified that I can copy the correct characters, but they do not
appear.
> 2. xterm -en UTF-8
Same messages, but the term appears and immediately disappears.
> 3. or use cygwin-1.7 with proper locale settings.
More details?
> 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.
Nothing but spaces and question marks. However, they can be copied
here:
こんにちは 안녕하세요? 你好
Best regards,
Yongwei
--
Wu Yongwei
URL: http://wyw.dcweb.cn/
Re: OpenGL-1.1.0 compile problem in cygwin-1.7
"Phan, Linh H" wrote: > gluTessCallback(tobj, (GLenum)GLU_BEGIN, (void (*)())glBegin); > gluTessCallback(tobj, (GLenum)GLU_END, glEnd); > gluTessCallback(tobj, (GLenum)GLU_VERTEX, (void (*)())glVertex2fv); > } > > And that fixed it for glEnd, but I don't know how to fix the glBegin and > glVertex2fv. This is not my code; it's part of the SGI OpenInventor library. You can use a typedef to make life a little easier. There's already one in glu.h that you can reuse (although it looks like it's not meant to be part of the public interface so it might not be the best idea to rely on it): typedef void (APIENTRY *_GLUfuncptr)(); Then the cast becomes just "(_GLUfuncptr)whatever". Brian -- 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: OpenGL-1.1.0 link problem (glXMakeCurrent undefined symbols)
"Phan, Linh H" wrote: > Hi, Hi Linh, > I'm trying to port OpenInventor code and using the new opengl-1.1.0 and I > am getting > undefined _glXMakeCurrent symbols: > /usr/bin/CC -g Main.o ClassDef.o Man.o Reader.o Writer.o BuildIssues.o > -lInventor -lstdc++ > -L/usr/X11R6/lib -L/usr/local/lib -limage -ljpeg -liconv -lFL -lfreetype > -lglu32 -lopengl32 -lXm -lXt -lXext -lXi -lX11 -lm -o ivman > /usr/local/lib/libInventor.a(So.o): In function > `_ZN19SoOffscreenRendererD2Ev': > /usr/local/src/inventor2/lib/database/src/so/SoOffscreenRenderer.c++:173: > undefined reference to > `_glXDestroyGLXPixmap' > /usr/local/src/inventor2/lib/database/src/so/SoOffscreenRenderer.c++:174: > undefined reference to > `_glXDestroyContext' > /usr/local/src/inventor2/lib/database/src/so/SoOffscreenRenderer.c++:755: > undefined reference to > `_glXMakeCurrent' > ... > I could see it in: > [EMAIL PROTECTED] ...inventor2/lib]$ nm /usr/X11R6/lib/libGL-1.dll.a |grep > glXMakeCurrent > I __imp__glXMakeCurrentReadSGI > T _glXMakeCurrentReadSGI > I __imp__glXMakeCurrent > T _glXMakeCurrent > What library in the new opengl-1.1.0 can I used to fix this problem? > Thank you, > Linh > Yeurk! The problem here is that you are trying to mix to incompatible things: 1- libraries from the w32api package (-lglu32 -lopengl32) which are about displaying openGL graphics directly through a native Windows interface (Win32) without any X server; 2- some other librairies (-lX...) that are about displaying through an X server. Than cannot work. You must make up your mind: Either you follow the Win32 road and you move your discussion to cygwin at cygwin dot com (as Yaakov suggested). Or you follow the X server road. As OpenInventor is some SGI thing, it is probably the best choice. In that case, you should update all your X11-related packages (-L/usr/X11R6/lib is related to the old version). In particular, you will need the following packages: libGL-devel, libGL1, libGLU-devel, libGLU1, which are about displaying openGL graphics through an X server. In that case, keep the discussion at cygwin-xfree at cygwin dot com. - André Bleau, Cygwin's volunteer OpenGL package maintainer. Please direct any question or comment about the OpenGL package to cygwin at cygwin dot com _ -- 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: OpenGL-1.1.0 compile problem in cygwin-1.7
"Phan, Linh H" wrote:
>
> Hi Brian,
>
> Can you show me how I can fix the cast? I tried this:
>
> #include
> #include
> void test (void)
> {
> GLUtesselator *tobj = (GLUtesselator *)gluNewTess();
> gluTessCallback(tobj, (GLenum)GLU_BEGIN, (void (*)())glBegin);
> gluTessCallback(tobj, (GLenum)GLU_END, glEnd);
> gluTessCallback(tobj, (GLenum)GLU_VERTEX, (void (*)())glVertex2fv);
> }
>
> And that fixed it for glEnd, but I don't know how to fix the glBegin and
> glVertex2fv.
> This is not my code; it's part of the SGI OpenInventor library.
>
> Thank you,
>
> Linh
>
Hi Linh,
Did you try:
#include
#include
void test (void)
{
GLUtesselator *tobj = gluNewTess();
gluTessCallback(tobj, (GLenum)GLU_BEGIN, glBegin);
gluTessCallback(tobj, (GLenum)GLU_END, glEnd);
gluTessCallback(tobj, (GLenum)GLU_VERTEX, glVertex2fv);
}
Anyway, glu.h shows that the prototype for gluTessCallback is:
GLAPI void APIENTRY gluTessCallback (GLUtesselator* tess, GLenum which,
_GLUfuncptr CallBackFunc);
so (_GLUfuncptr) is the obvious cast, no?
- André Bleau, Cygwin's volunteer OpenGL package maintainer.
Please direct any question or comment about the OpenGL package to cygwin at
cygwin dot com
_
--
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/
xterm-237-2 still has no UTF-8 support
This has been raised in the past: http://cygwin.com/ml/cygwin-xfree/2007-08/msg00082.html The recent xterm-237-2 still does not have the Unicode support enabled, even though it contains a uxterm script. It seems the old xterm-202-1, which has UTF-8 support, no longer works with the new xserver :-(. Any help? Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/ -- 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/
