[Xwin 1.7]: copy from rxvt-x to windows application does not work
Hi, If I run rxvt-x (1.5 or 1.7) with Xwin (1.7), when I select something in the terminal output and then type Ctrl-V in any Windows application, this does not work. Some application say that the clipboard is like corrupted. Sometimes, if I type Ctrl-V several times, after a while, the text is pasted. If I use Xwin 1.5 or rxvt-native it works fine (with rxvt version either 1.5 or 1.7). Any clue for that? Frédéric -- 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/
winsup/cygwin ChangeLog path.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2009-05-29 20:18:50 Modified files: cygwin : ChangeLog path.cc Log message: * path.cc (cwdstuff::set): Rewrite previous change to properly test the end of the buffer. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.4494r2=1.4495 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/path.cc.diff?cvsroot=uberbaumr1=1.548r2=1.549
winsup/cygwin ChangeLog fhandler_console.cc
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2009-05-30 05:51:41 Modified files: cygwin : ChangeLog fhandler_console.cc Log message: * fhandler_console.cc (fhandler_console::read): Convert backspace key to DEL. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.4495r2=1.4496 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/fhandler_console.cc.diff?cvsroot=uberbaumr1=1.191r2=1.192
[1.7] does LD_PRELOAD support more than 1 dll ?
Hi All, I was trying to understand why LD_PRELOAD does not work for octave, that have 3 dlls specified on LD_PRELOAD and I discovered that it seems to handle only 1 dll and not more. If I specify 2 or more dlls, LD_PRELOAD stop to work $uname -a CYGWIN_NT-5.1 ITQMOZCAS2NB007 1.7.0(0.210/5/3) 2009-05-15 17:15 i686 Cygwin as test case I used the fltk-demos sudoku, and chosen 2 of the dll's $ cygcheck sudoku [snip] C:\cygwin2\bin\cygjpeg-62.dll C:\cygwin2\bin\cygpng12.dll [snip] copied them in a tmp directory mkdir /tmp/prova cp cygjpeg-62.dll cygpng12.dll /tmp/prova the outcome is: $ LD_PRELOAD=/tmp/prova/cygjpeg-62.dll /tmp/prova/cygpng12.dll sudoku 3 [main] bash 12924 C:\cygwin2\bin\bash.exe: *** fatal error - error while loading shared libraries: /tmp/prova/cygjpeg-62.dll /tmp/prova/cygpng12.dll: cannot open shared object file: No such file or directory Hangup while if I specify only 1 dll $ LD_PRELOAD=/tmp/prova/cygjpeg-62.dll sudoku it works. Is it a bug, feature or a BLODA issue ? Thanks Marco -- 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] does LD_PRELOAD support more than 1 dll ?
On Fri, May 29, 2009 at 09:10, Marco Atzeri marco_atz...@yahoo.it wrote: the outcome is: $ LD_PRELOAD=/tmp/prova/cygjpeg-62.dll /tmp/prova/cygpng12.dll sudoku 3 [main] bash 12924 C:\cygwin2\bin\bash.exe: *** fatal error - error while loading shared libraries: /tmp/prova/cygjpeg-62.dll /tmp/prova/cygpng12.dll: cannot open shared object file: No such file or directory Hangup while if I specify only 1 dll $ LD_PRELOAD=/tmp/prova/cygjpeg-62.dll sudoku it works. Is it a bug, feature or a BLODA issue ? I don't know if it still stands up to date, but after a minor googling, I stumbled upon this message: http://www.cygwin.com/ml/cygwin-cvs/2005-q2/msg00031.html Where it reads: * hookapi.cc (ld_preload): Use colon as a separator rather than space. So, it might worth the test :) Hope it helps. ___ Julio Costa -- 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/
R: [1.7] does LD_PRELOAD support more than 1 dll ?
--- Ven 29/5/09, Marco Atzeri ha scritto: Da: Marco Atzeri Oggetto: [1.7] does LD_PRELOAD support more than 1 dll ? A: cygwin@cygwin.com Data: Venerdì 29 maggio 2009, 10:10 Hi All, I was trying to understand why LD_PRELOAD does not work for octave, that have 3 dlls specified on LD_PRELOAD and I discovered that it seems to handle only 1 dll and not more. If I specify 2 or more dlls, LD_PRELOAD stop to work $uname -a CYGWIN_NT-5.1 ITQMOZCAS2NB007 1.7.0(0.210/5/3) 2009-05-15 17:15 i686 Cygwin as test case I used the fltk-demos sudoku, and chosen 2 of the dll's $ cygcheck sudoku [snip] C:\cygwin2\bin\cygjpeg-62.dll C:\cygwin2\bin\cygpng12.dll [snip] copied them in a tmp directory mkdir /tmp/prova cp cygjpeg-62.dll cygpng12.dll /tmp/prova the outcome is: $ LD_PRELOAD=/tmp/prova/cygjpeg-62.dll /tmp/prova/cygpng12.dll sudoku 3 [main] bash 12924 C:\cygwin2\bin\bash.exe: *** fatal error - error while loading shared libraries: /tmp/prova/cygjpeg-62.dll /tmp/prova/cygpng12.dll: cannot open shared object file: No such file or directory Hangup while if I specify only 1 dll $ LD_PRELOAD=/tmp/prova/cygjpeg-62.dll sudoku it works. Is it a bug, feature or a BLODA issue ? Thanks Marco Answering myself. Must use : as separator LD_PRELOAD=/tmp/prova/cygjpeg-62.dll:/tmp/prova/cygpng12.dll sudoku is working. It seems that cygwin does not accept the space as separator in LD_PRELOAD as other systems Regards Marco -- 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: emacs -nw keypad, tpu-edt.el, and C-h
Date: Thu, 28 May 2009 18:10:51 +0100 From: Andy Koppe andy dot koppe at gmail.com rxvt: invoke with -backspacekey DEC xterm: invoke with -xrm *backarrowKey:false (or untick Backarrow Key in the Main Options menu) mintty: Choose ^? as backspace keycode on the Keys page of the options As far as I know, it can't be changed in the Cygwin console, presumably because Windows sends ^H for backspace to applications running in the console. That seems to be false, as evidenced by the native Windows build of Emacs running on the Command Prompt console with the -nw switch. Typing C-h l after several backspaces shows that Windows sends backspace to the application, not C-h. However, I'm not a Cygwin user, so perhaps the Command Prompt window is significantly different from what you call Cygwin console. Apologies if so. -- 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: limited connection numbers to X?
On Thu, May 28, 2009 at 7:14 PM, Larry Hall (Cygwin) reply-to-list-only...@cygwin.com wrote: jean-luc malet wrote: Hi, after opening about 15 to 20 connection to X, all further connection will end with an error can't connect to X server since I have lot of vim and xterm opened I must close some to open new ones... is it a known feature? it happens only on cygwin1.7 This is probably better sent to the cygwin-xfree list since it could be a X thing. it happened just after upgrading le cygwin.dll do 1.7, before it was working fine, X hasn't been upgraded if I'm correct so it seems more related to cygwin.dll and maybe socket limitation... JLM -- 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: emacs -nw keypad, tpu-edt.el, and C-h
Date: Thu, 28 May 2009 15:02:35 +0100 From: Andy Koppe andy dor koppe at gmail.com Ken Brown: A separate issue that has arisen in this thread is that when emacs runs in a cygwin terminal [*], it sees C-h as DEL instead of as the help key. Can someone familiar with cygwin terminals help with this? I'm speculating again (bad habit), but it seems that the keycodes are being processed before they reach emacs, so that C-h becomes indistinguishable from the Backspace key. Careful, you're straying into a pseudo-religious warzone here. :) There's an ancient and pointless argument about whether the Backspace key should send ^H (0x08) or ^? (0x7F). Actually, this holy war can be bypassed, without sacrificing Emacs correctly working on a console. What the console should send for that is the Backspace function key. Emacs already takes care of converting this to DEL. The following is from a native Windows build of Emacs 23 running under -nw in the Windows standard Command Prompt window: DEL (translated from backspace) runs the command delete-backward-char This message was caused by typing C-h c and then pressing the backspace key. -- 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: emacs -nw keypad, tpu-edt.el, and C-h
On 5/29/2009 6:35 AM, Eli Zaretskii wrote: Date: Thu, 28 May 2009 15:02:35 +0100 From: Andy Koppe andy dor koppe at gmail.com There's an ancient and pointless argument about whether the Backspace key should send ^H (0x08) or ^? (0x7F). Actually, this holy war can be bypassed, without sacrificing Emacs correctly working on a console. What the console should send for that is the Backspace function key. Makes sense to me. Andy, is there any reason all cygwin terminals shouldn't do this (including mintty)? This already happens under X, and users would then have consistent behavior. Ken -- 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: emacs -nw keypad, tpu-edt.el, and C-h
Actually, this holy war can be bypassed, without sacrificing Emacs correctly working on a console. What the console should send for that is the Backspace function key. Makes sense to me. Andy, is there any reason all cygwin terminals shouldn't do this (including mintty)? This already happens under X, and users would then have consistent behavior. What is the Backspace function key, i.e. what character sequence does that correspond to? Andy -- 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: Upgrade to cygwin 1.7 seemed to trash bash profile, path
On 5/28/2009 7:03 PM, Christopher Faylor wrote: I'm not really following this discussion closely but there should not, by default, be any entries for /usr/lib or /usr/bin in your /etc/fstab file. I've actually come across one situation where things don't work right if those lines are missing. I often use 'ssh admin-u...@localhost' to simulate 'su'. After deleting the entry for /usr/bin from /etc/fstab, this produces the following: -bash: /usr/bin/tr: No such file or directory -bash: /usr/bin/sed: No such file or directory $ ls /usr/bin ls: cannot access /usr/bin: No such file or directory The problem doesn't occur in the other direction. In other words, if I'm logged in as an administrator and then do 'ssh non-admin-u...@localhost', there's no problem. And everything is fine with the entry for /usr/bin restored to /etc/fstab. Ken -- 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.0-48: [BUG] Passing characters above 128 from bash command line
Hi. The encoding of C locale is ASCII, and not ISO-8859-1. I don't think ASCII is the same as ISO-8859-1. Does it work on LANG=en_US.ISO-8859-1? 2009/5/29 Edward Lam edw...@sidefx.com: Alexey Borzenkov wrote: On Thu, May 28, 2009 at 7:28 PM, Edward Lam edw...@sidefx.com wrote: PS. In case you haven't noticed, copyright.txt is not a long file. It consists of a single byte, 0xA9. Did you try utf-8 encoding copyright.txt? Perhaps your locale is utf-8 and the encoder fails. How is one supposed to determine one's locale in cygwin? I do NOT have LANG, or any of the LC environment variables set. I even tried explicitly setting LANG=C and it still fails. The problem does seem to stem from the new UTF-8 support in cygwin 1.7. However, I think something is going on here that is unexpected because trying something similar on Linux has no problems. To confirm that it was an UTF-8 related problem, let me repeat the steps slightly differently again. Here we assume that I've already got bug.exe compiled which simply prints out its arguments. $ export LANG=C $ ./bug arg1 before `cat copyright.txt` after arg3 0: E:\cygwin1.7\tmp\bug.exe 1: arg1 2: before *Notice that argc is 3 when it should be 4!* $ piconv -f iso-8859-1 -t utf8 copyright.txt fubar.txt $ ./bug arg1 before `cat fubar.txt` after arg3 0: E:\cygwin1.7\tmp\bug.exe 1: arg1 2: before © after 3: arg3 *So now everything works because I converted the character into UTF-8.* I think what this points to is some form of invalid source encoding of the command line argument when spawning NATIVE applications. Here's what happens when I try to compile bug.c using cygwin's gcc: $ gcc bug.c -o bug-gcc.exe $ ./bug-gcc arg1 before `cat copyright.txt` after arg3 0: ./bug-gcc 1: arg1 2: before © after 3: arg3 So there seems to be some sort of special marshaling of the command line arguments that only works when spawning cygwin apps, but breaks when running under native apps. Regards, -Edward -- 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/ -- IWAMURO Motnori http://vmi.jp/ -- 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: Upgrade to cygwin 1.7 seemed to trash bash profile, path
Aaron Humphrey wrote: So, in the end, reinstalling didn't do much. And I got a bunch of Cannot open (null) for reading (error not guaranteed to be accurate), usually when it was trying to install gzipped man pages or something. (Times like these I wonder why I persist in downloading every cygwin package on the mirror when I use only a fraction of them. Compulsive behaviour, I guess.) Perhaps there is something interesting to be found in setup.log.full. My impression is that you were installing from the Internet rather than downloading and then installing. Is that right? In any case, I was able to fix the problem by recreating /etc/profile from /etc/skel. Why /etc/profile got trashed by the upgrade to 1.7, I don't know, but apparently it did. So now I once again have PATH initialized properly and my bash prompt looks normal. Was there an '/etc/profile' file in any form before you recreated it? -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: Upgrade to cygwin 1.7 seemed to trash bash profile, path
Date: Fri, 29 May 2009 10:56:03 -0400 From: kbrown Subject: Re: Upgrade to cygwin 1.7 seemed to trash bash profile, path On 5/28/2009 7:03 PM, Christopher Faylor wrote: I'm not really following this discussion closely but there should not, by default, be any entries for /usr/lib or /usr/bin in your /etc/fstab file. I've actually come across one situation where things don't work right if those lines are missing. I often use 'ssh admin-u...@localhost' to simulate 'su'. After deleting the entry for /usr/bin from /etc/fstab, this produces the following: -bash: /usr/bin/tr: No such file or directory -bash: /usr/bin/sed: No such file or directory $ ls /usr/bin ls: cannot access /usr/bin: No such file or directory The problem doesn't occur in the other direction. In other words, if I'm logged in as an administrator and then do 'ssh non-admin-u...@localhost', there's no problem. And everything is fine with the entry for /usr/bin restored to /etc/fstab. Hi... This is the same symptom I had. The 2009-05-18 (and 2009-05-28) snapshot fixed it. Thanks, ...Karl _ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_BR_life_in_synch_052009 -- 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: R: [1.7] does LD_PRELOAD support more than 1 dll ?
On Fri, May 29, 2009 at 09:34:36AM +, Marco Atzeri wrote: It seems that cygwin does not accept the space as separator in LD_PRELOAD as other systems And lets just all take a moment of silence for a second to see if we can discern why that might be. cgf -- 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.0-48: [BUG] Passing characters above 128 from bash command line
IWAMURO Motonori wrote: The encoding of C locale is ASCII, and not ISO-8859-1. I don't think ASCII is the same as ISO-8859-1. Does it work on LANG=en_US.ISO-8859-1? No, it doesn't. Mind you though, I haven't managed to get piconv to recognize any of my LANG settings other than C in cygwin 1.7. $ export LANG=LANG=en_US.ISO-8859-1 $ piconv perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset), LANG = LANG=en_US.ISO-8859-1 are supported and installed on your system. (... usage omitted...) $ ./bug arg1 before `cat copyright.txt` after arg3 0: E:\cygwin1.7\tmp\bug.exe 1: arg1 2: before Regards, -Edward 2009/5/29 Edward Lam edw...@sidefx.com: Alexey Borzenkov wrote: On Thu, May 28, 2009 at 7:28 PM, Edward Lam edw...@sidefx.com wrote: PS. In case you haven't noticed, copyright.txt is not a long file. It consists of a single byte, 0xA9. Did you try utf-8 encoding copyright.txt? Perhaps your locale is utf-8 and the encoder fails. How is one supposed to determine one's locale in cygwin? I do NOT have LANG, or any of the LC environment variables set. I even tried explicitly setting LANG=C and it still fails. The problem does seem to stem from the new UTF-8 support in cygwin 1.7. However, I think something is going on here that is unexpected because trying something similar on Linux has no problems. To confirm that it was an UTF-8 related problem, let me repeat the steps slightly differently again. Here we assume that I've already got bug.exe compiled which simply prints out its arguments. $ export LANG=C $ ./bug arg1 before `cat copyright.txt` after arg3 0: E:\cygwin1.7\tmp\bug.exe 1: arg1 2: before *Notice that argc is 3 when it should be 4!* $ piconv -f iso-8859-1 -t utf8 copyright.txt fubar.txt $ ./bug arg1 before `cat fubar.txt` after arg3 0: E:\cygwin1.7\tmp\bug.exe 1: arg1 2: before © after 3: arg3 *So now everything works because I converted the character into UTF-8.* I think what this points to is some form of invalid source encoding of the command line argument when spawning NATIVE applications. Here's what happens when I try to compile bug.c using cygwin's gcc: $ gcc bug.c -o bug-gcc.exe $ ./bug-gcc arg1 before `cat copyright.txt` after arg3 0: ./bug-gcc 1: arg1 2: before © after 3: arg3 So there seems to be some sort of special marshaling of the command line arguments that only works when spawning cygwin apps, but breaks when running under native apps. Regards, -Edward -- 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/ -- 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: R: [1.7] does LD_PRELOAD support more than 1 dll ?
Christopher Faylor wrote: On Fri, May 29, 2009 at 09:34:36AM +, Marco Atzeri wrote: It seems that cygwin does not accept the space as separator in LD_PRELOAD as other systems And lets just all take a moment of silence for a second to see if we can discern why that might be. The ubiquity of paths containing spaces on windows file systems? cheers, DaveK -- [ inb4: But what if you want to write LD_PRELOAD using DOS paths? ] -- 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.0-48: [BUG] Passing characters above 128 from bash command line
I think that you should set export LANG=en_US.ISO-8859-1 instead of export LANG=LANG=en_US.ISO-8859-1. 2009/5/30 Edward Lam edw...@sidefx.com: IWAMURO Motonori wrote: The encoding of C locale is ASCII, and not ISO-8859-1. I don't think ASCII is the same as ISO-8859-1. Does it work on LANG=en_US.ISO-8859-1? No, it doesn't. Mind you though, I haven't managed to get piconv to recognize any of my LANG settings other than C in cygwin 1.7. $ export LANG=LANG=en_US.ISO-8859-1 $ piconv perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset), LANG = LANG=en_US.ISO-8859-1 are supported and installed on your system. (... usage omitted...) $ ./bug arg1 before `cat copyright.txt` after arg3 0: E:\cygwin1.7\tmp\bug.exe 1: arg1 2: before Regards, -Edward 2009/5/29 Edward Lam edw...@sidefx.com: Alexey Borzenkov wrote: On Thu, May 28, 2009 at 7:28 PM, Edward Lam edw...@sidefx.com wrote: PS. In case you haven't noticed, copyright.txt is not a long file. It consists of a single byte, 0xA9. Did you try utf-8 encoding copyright.txt? Perhaps your locale is utf-8 and the encoder fails. How is one supposed to determine one's locale in cygwin? I do NOT have LANG, or any of the LC environment variables set. I even tried explicitly setting LANG=C and it still fails. The problem does seem to stem from the new UTF-8 support in cygwin 1.7. However, I think something is going on here that is unexpected because trying something similar on Linux has no problems. To confirm that it was an UTF-8 related problem, let me repeat the steps slightly differently again. Here we assume that I've already got bug.exe compiled which simply prints out its arguments. $ export LANG=C $ ./bug arg1 before `cat copyright.txt` after arg3 0: E:\cygwin1.7\tmp\bug.exe 1: arg1 2: before *Notice that argc is 3 when it should be 4!* $ piconv -f iso-8859-1 -t utf8 copyright.txt fubar.txt $ ./bug arg1 before `cat fubar.txt` after arg3 0: E:\cygwin1.7\tmp\bug.exe 1: arg1 2: before © after 3: arg3 *So now everything works because I converted the character into UTF-8.* I think what this points to is some form of invalid source encoding of the command line argument when spawning NATIVE applications. Here's what happens when I try to compile bug.c using cygwin's gcc: $ gcc bug.c -o bug-gcc.exe $ ./bug-gcc arg1 before `cat copyright.txt` after arg3 0: ./bug-gcc 1: arg1 2: before © after 3: arg3 So there seems to be some sort of special marshaling of the command line arguments that only works when spawning cygwin apps, but breaks when running under native apps. Regards, -Edward -- 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/ -- 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/ -- IWAMURO Motnori http://vmi.jp/ -- 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: R: [1.7] does LD_PRELOAD support more than 1 dll ?
On Fri, May 29, 2009 at 05:02:01PM +0100, Dave Korn wrote: Christopher Faylor wrote: On Fri, May 29, 2009 at 09:34:36AM +, Marco Atzeri wrote: It seems that cygwin does not accept the space as separator in LD_PRELOAD as other systems And lets just all take a moment of silence for a second to see if we can discern why that might be. The ubiquity of paths containing spaces on windows file systems? Yes, I probably never should have done it though since it isn't compatible with Linux. cgf -- 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.0-48: [BUG] Passing characters above 128 from bash command line
IWAMURO Motonori wrote: I think that you should set export LANG=en_US.ISO-8859-1 instead of export LANG=LANG=en_US.ISO-8859-1. Ah, sorry, copy/paste error. Yes, that finally works. Thank you! I think there is still a bug here? I set LANG=C, then shouldn't be just NOT doing any encoding, thus work? If I do this on Linux, it works. If I use a cygwin compiled app, it also works. -Edward 2009/5/30 Edward Lam edw...@sidefx.com: IWAMURO Motonori wrote: The encoding of C locale is ASCII, and not ISO-8859-1. I don't think ASCII is the same as ISO-8859-1. Does it work on LANG=en_US.ISO-8859-1? No, it doesn't. Mind you though, I haven't managed to get piconv to recognize any of my LANG settings other than C in cygwin 1.7. $ export LANG=LANG=en_US.ISO-8859-1 $ piconv perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset), LANG = LANG=en_US.ISO-8859-1 are supported and installed on your system. (... usage omitted...) $ ./bug arg1 before `cat copyright.txt` after arg3 0: E:\cygwin1.7\tmp\bug.exe 1: arg1 2: before Regards, -Edward 2009/5/29 Edward Lam edw...@sidefx.com: Alexey Borzenkov wrote: On Thu, May 28, 2009 at 7:28 PM, Edward Lam edw...@sidefx.com wrote: PS. In case you haven't noticed, copyright.txt is not a long file. It consists of a single byte, 0xA9. Did you try utf-8 encoding copyright.txt? Perhaps your locale is utf-8 and the encoder fails. How is one supposed to determine one's locale in cygwin? I do NOT have LANG, or any of the LC environment variables set. I even tried explicitly setting LANG=C and it still fails. The problem does seem to stem from the new UTF-8 support in cygwin 1.7. However, I think something is going on here that is unexpected because trying something similar on Linux has no problems. To confirm that it was an UTF-8 related problem, let me repeat the steps slightly differently again. Here we assume that I've already got bug.exe compiled which simply prints out its arguments. $ export LANG=C $ ./bug arg1 before `cat copyright.txt` after arg3 0: E:\cygwin1.7\tmp\bug.exe 1: arg1 2: before *Notice that argc is 3 when it should be 4!* $ piconv -f iso-8859-1 -t utf8 copyright.txt fubar.txt $ ./bug arg1 before `cat fubar.txt` after arg3 0: E:\cygwin1.7\tmp\bug.exe 1: arg1 2: before © after 3: arg3 *So now everything works because I converted the character into UTF-8.* I think what this points to is some form of invalid source encoding of the command line argument when spawning NATIVE applications. Here's what happens when I try to compile bug.c using cygwin's gcc: $ gcc bug.c -o bug-gcc.exe $ ./bug-gcc arg1 before `cat copyright.txt` after arg3 0: ./bug-gcc 1: arg1 2: before © after 3: arg3 So there seems to be some sort of special marshaling of the command line arguments that only works when spawning cygwin apps, but breaks when running under native apps. Regards, -Edward -- 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/ -- 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/ -- 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: Long file names not working in cygwin-1.7.0-48
Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com wrote in message news:20090528051242.ga13...@ednor.casa.cgf.cx... On Wed, May 27, 2009 at 05:11:55PM -0700, jpa wrote: # Create long directory path fails (255 a's/255 b's mkdir -p /tmp/[SNIP long dir name] Thanks for the test case. This should be fixed in the next snapshot which is building now. I'll be in bed before it finishes but if there are problems uploading it I'll restart it tomorrow. http://cygwin.com/snapshots/ Btw, the second set of b's isn't necessary. A single b would trigger the problem. cgf Thank you. This problem has been fixed with the 5-28-2009 snapshot. Unfortunately I now have a different but probably related problem. I am unable to create a file or directory with a period as the first character. mkdir .test returns /bin/mkdir: cannot create directory `.test': No such file or directory However this only happens in my cwrsync installation which uses cygwin. Rolling back to 1.7.0-48 allows periods at the beginning. In my test install of cygwin on a WinXP box I can't trigger the error. jpa Cygwin Configuration Diagnostics Current System Time: Fri May 29 09:30:16 2009 Windows 2003 Server R2 Ver 5.2 Build 3790 Service Pack 2 Running in Terminal Service session Path: C:\Perl\site\bin C:\Perl\bin C:\Program Files\Windows Resource Kits\Tools\ C:\Program Files\Common Files\Pervasive Software Shared\pvswcore D:\ProHome\Timberline\SHARED\ C:\PVSW\BIN C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Files\Citrix\System32\Citrix\IMA C:\Program Files\Citrix\System32\Citrix\IMA\Subsystems C:\WINDOWS\System32\Citrix\IMA C:\Program Files\Citrix\system32 C:\Program Files\Common Files\Citrix\System32\ C:\Program Files\Common Files\Crystal Decisions\2.5\bin C:\Program Files\MySQL\MySQL Server 5.0\bin Output from C:\Program Files\ICW\bin\id.exe (nontsec) UID: 400(Administrator) GID: 401(mkpasswd) 401(mkpasswd) Output from C:\Program Files\ICW\bin\id.exe (ntsec) UID: 400(Administrator) GID: 401(mkpasswd) 401(mkpasswd) SysDir: C:\WINDOWS\system32 WinDir: C:\Documents and Settings\Administrator\WINDOWS Path = 'C:\Perl\site\bin;C:\Perl\bin;C:\Program Files\Windows Resource Kits\Tools\;C:\Program Files\Common Files\Pervasive Software Shared\pvswcore;D:\ProHome\Timberline\SHARED\;C:\PVSW\BIN;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Citrix\System32\Citrix\IMA;C:\Program Files\Citrix\System32\Citrix\IMA\Subsystems;C:\WINDOWS\System32\Citrix\IMA;C:\Program Files\Citrix\system32;C:\Program Files\Common Files\Citrix\System32\;C:\Program Files\Common Files\Crystal Decisions\2.5\bin;C:\Program Files\MySQL\MySQL Server 5.0\bin' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' APPDATA = 'C:\Documents and Settings\Administrator\Application Data' CLASSPATH = 'C:\PVSW\bin\pvjdbc2x.jar;C:\PVSW\bin\pvjdbc2.jar;C:\PVSW\bin\jpscs.jar;C:\PVSW\BIN\PVJDBC2X.JAR;C:\PVSW\BIN\PVJDBC2.JAR' CLIENTNAME = 'HOME-PC' ClusterLog = 'C:\WINDOWS\Cluster\cluster.log' CommonProgramFiles = 'C:\Program Files\Common Files' COMPUTERNAME = 'GMISRVDR02' ComSpec = 'C:\WINDOWS\system32\cmd.exe' FP_NO_HOST_CHECK = 'NO' HOMEDRIVE = 'C:' HOMEPATH = '\Documents and Settings\Administrator' LOGONSERVER = '\\GMISRVDR01' NUMBER_OF_PROCESSORS = '1' OS = 'Windows_NT' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = 'x86' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 2 Stepping 8, GenuineIntel' PROCESSOR_LEVEL = '15' PROCESSOR_REVISION = '0208' ProgramFiles = 'C:\Program Files' PROMPT = '$P$G' SESSIONNAME = 'RDP-Tcp#10' SystemDrive = 'C:' SystemRoot = 'C:\WINDOWS' TEMP = 'C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp' TMP = 'C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp' USERDNSDOMAIN = 'GEONERCO.COM' USERDOMAIN = 'GEONERCO' USERNAME = 'Administrator' USERPROFILE = 'C:\Documents and Settings\Administrator' VSL = 'C:\PVSW\\bin' windir = 'C:\WINDOWS' HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = '/cygdrive' cygdrive flags = 0x002a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = 'C:\Program Files\ICW' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = 'C:\Program Files\ICW\bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options obcaseinsensitive set to 1 a: fd N/AN/A c: hd NTFS 20481Mb 57% CP CS UN PA FC d: hd NTFS 36860Mb 58% CP CS UN PA FC Accounting e: cd N/AN/A f: hd
Re: Upgrade to cygwin 1.7 seemed to trash bash profile, path
On Fri, May 29, 2009 at 9:16 AM, Larry Hall wrote: Aaron Humphrey wrote: So, in the end, reinstalling didn't do much. And I got a bunch of Cannot open (null) for reading (error not guaranteed to be accurate), usually when it was trying to install gzipped man pages or something. (Times like these I wonder why I persist in downloading every cygwin package on the mirror when I use only a fraction of them. Compulsive behaviour, I guess.) Perhaps there is something interesting to be found in setup.log.full. Could be; I didn't have to a chance to look at it. My impression is that you were installing from the Internet rather than downloading and then installing. Is that right? I was, and I had chosen a different mirror last time I installed so it had to re-download more than it really needed to. I did also get the message that the download had not completed properly, but when I asked it to rerun it only downloaded two packages and then got the same error. In any case, I was able to fix the problem by recreating /etc/profile from /etc/skel. Why /etc/profile got trashed by the upgrade to 1.7, I don't know, but apparently it did. So now I once again have PATH initialized properly and my bash prompt looks normal. I think I meant /etc/defaults here, not /etc/skel. Was there an '/etc/profile' file in any form before you recreated it? No, there wasn't. I don't remember if I had ever modified it before it got trashed, either. -- --Alfvaen (Web page: http://www.telusplanet.net/public/alfvaen/ ) Song In My Head--Kid Creole The Coconuts:The Love We Have Current Book--Carol Berg:Transformation Constant change is here to stay. -- 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: Long file names not working in cygwin-1.7.0-48
On Fri, May 29, 2009 at 09:39:23AM -0700, jpa wrote: Christopher Faylor wrote: On Wed, May 27, 2009 at 05:11:55PM -0700, jpa wrote: # Create long directory path fails (255 a's/255 b's mkdir -p /tmp/[SNIP long dir name] Thanks for the test case. This should be fixed in the next snapshot which is building now. I'll be in bed before it finishes but if there are problems uploading it I'll restart it tomorrow. http://cygwin.com/snapshots/ Btw, the second set of b's isn't necessary. A single b would trigger the problem. Thank you. This problem has been fixed with the 5-28-2009 snapshot. Unfortunately I now have a different but probably related problem. I am unable to create a file or directory with a period as the first character. mkdir .test returns /bin/mkdir: cannot create directory `.test': No such file or directory l:\bash bash-3.2$ cd /tmp bash-3.2$ mkdir .test bash-3.2$ exit exit However this only happens in my cwrsync installation which uses cygwin. Rolling back to 1.7.0-48 allows periods at the beginning. In my test install of cygwin on a WinXP box I can't trigger the error. Sorry but I don't care about cwrsync. If you can generate a test case for a bona fide Cygwin installation, I'll investigate. FWIW, it is hard to believe that the change I made for this would affect files beginning with dots in any way. cgf -- 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.0-48: [BUG] Passing characters above 128 from bash command line
On Fri, May 29, 2009 at 8:22 PM, Edward Lam edw...@sidefx.com wrote: I think there is still a bug here? I set LANG=C, then shouldn't be just NOT doing any encoding, thus work? If I do this on Linux, it works. If I use a cygwin compiled app, it also works. On Linux, internally, system uses multibyte strings (it is encoding agnostic even), but on Windows, system uses unicode strings, so cygwin has to decode your byte sequences somehow to pass them to non-cygwin processes as unicode (the fact that cygwin now understands unicode is a huge plus to me). In earlier discussions it was decided that cygwin C locale should use utf-8 encoding, because file system internally uses unicode it's the safest default to represent all possible filenames, etc. In previous cygwin versions, your byte sequences were just silently converted using your system's codepage (by the system itself, even), so if you want the old behavior you should set LANG=en_US.CP1252. The only bug here is that the arguments are truncated instead of using some kind of a replacement character, is it related to some posix complience, like with wprintf? -- 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/
cygpath -a anomaly
With cygdrive prefix = /, from the root directory of a drive (e.g., /c = c:\ or /h = h:\), when asking for the absolute unix path with -au, cygpath doubles the / between the drive letter and the first directory of the path. /h echo Home | cygpath -au -f - /h//Home /h echo Home | cygpath -aw -f - h:\Home This does not happen when one is not in the root directory of the drive. /h cd Home /h/Home echo cartoons | cygpath -au -f - /h/Home/cartoons /h/Home echo cartoons | cygpath -aw -f - h:\Home\cartoons This does not happen when /h cd .. /h echo Home\\cartoons | cygpath -au -f - /h//Home/cartoons /h echo Home/cartoons | cygpath -aw -f - h:\Home\cartoons This is with cygwin 1.5, everything up to date. Note that this also happens on C:. Cygwin is in c:\\cygwin. - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- 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: Long file names not working in cygwin-1.7.0-48
Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com wrote in message news:20090529183702.ga28...@ednor.casa.cgf.cx... On Fri, May 29, 2009 at 09:39:23AM -0700, jpa wrote: Christopher Faylor wrote: On Wed, May 27, 2009 at 05:11:55PM -0700, jpa wrote: # Create long directory path fails (255 a's/255 b's mkdir -p /tmp/[SNIP long dir name] Thanks for the test case. This should be fixed in the next snapshot which is building now. I'll be in bed before it finishes but if there are problems uploading it I'll restart it tomorrow. http://cygwin.com/snapshots/ Btw, the second set of b's isn't necessary. A single b would trigger the problem. Thank you. This problem has been fixed with the 5-28-2009 snapshot. Unfortunately I now have a different but probably related problem. I am unable to create a file or directory with a period as the first character. mkdir .test returns /bin/mkdir: cannot create directory `.test': No such file or directory l:\bash bash-3.2$ cd /tmp bash-3.2$ mkdir .test bash-3.2$ exit exit However this only happens in my cwrsync installation which uses cygwin. Rolling back to 1.7.0-48 allows periods at the beginning. In my test install of cygwin on a WinXP box I can't trigger the error. Sorry but I don't care about cwrsync. If you can generate a test case for a bona fide Cygwin installation, I'll investigate. FWIW, it is hard to believe that the change I made for this would affect files beginning with dots in any way. cgf Thanks for testing. I can't tell what's different about my cwrsync config so I strace'd a test mkdir with a period using a 1.7.0-48 and snapshot cygwin dll and looked for differences. I found several differences where a \ was at the end of some lines where it wasn't in the successfull pass. I've reduced the strace from an unsuccessful run to this: mount_info::conv_to_posix_path: conv_to_posix_path (C:\Program Files\ICW\Bin\, no-keep-rel, add-slash) normalize_win32_path: C:\Program Files\ICW\Bin\ = normalize_win32_path (C:\Program Files\ICW\Bin\) mount_info::conv_to_posix_path: /Bin/ = conv_to_posix_path (C:\Program Files\ICW\Bin\) cwdstuff::get: posix /Bin/ cwdstuff::get: (/Bin/) = cwdstuff::get (0xA701A0, 32768, 1, 0), errno 0 normalize_posix_path: /Bin//.test = normalize_posix_path (.test) mount_info::conv_to_win32_path: conv_to_win32_path (/Bin//.test) set_flags: flags: binary (0x2) mount_info::conv_to_win32_path: src_path /Bin//.test, dst C:\Program Files\ICW\Bin\\.test, flags 0x3000A, rc 0 __set_errno: save_errno::~save_errno():47 val 0 __set_errno: save_errno::~save_errno():47 val 0 symlink_info::check: 0xC033 = NtQueryInformationFile (\??\C:\Program Files\ICW\Bin\\.test) symlink_info::check: not a symlink symlink_info::check: 0 = symlink.check (C:\Program Files\ICW\Bin\\.test, 0x223848) (0x3000A) mount_info::conv_to_win32_path: conv_to_win32_path (/Bin/) Where a successful run produces this: mount_info::conv_to_posix_path: conv_to_posix_path (C:\Program Files\ICW\Bin, no-keep-rel, no-add-slash) normalize_win32_path: C:\Program Files\ICW\Bin = normalize_win32_path (C:\Program Files\ICW\Bin) mount_info::conv_to_posix_path: /Bin = conv_to_posix_path (C:\Program Files\ICW\Bin) cwdstuff::get: posix /Bin cwdstuff::get: (/Bin) = cwdstuff::get (0xA701A0, 32768, 1, 0), errno 0 normalize_posix_path: /Bin/.test = normalize_posix_path (.test) mount_info::conv_to_win32_path: conv_to_win32_path (/Bin/.test) set_flags: flags: binary (0x2) mount_info::conv_to_win32_path: src_path /Bin/.test, dst C:\Program Files\ICW\Bin\.test, flags 0x3000A, rc 0 __set_errno: save_errno::~save_errno():47 val 0 __set_errno: save_errno::~save_errno():47 val 0 symlink_info::check: 0xC034 = NtQueryInformationFile (\??\C:\Program Files\ICW\Bin\.test) __set_errno: save_errno::~save_errno():47 val 0 __set_errno: save_errno::~save_errno():47 val 0 symlink_info::check: 0xC034 = NtQueryInformationFile (\??\C:\Program Files\ICW\Bin\.test.lnk) symlink_info::check: 0 = symlink.check (C:\Program Files\ICW\Bin\.test, 0x223848) (0x3000A) -- 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: cygpath -a anomaly
On Fri, May 29, 2009 at 03:20:28PM -0400, Buchbinder, Barry (NIH/NIAID) [E] wrote: With cygdrive prefix = /, from the root directory of a drive (e.g., /c = c:\ or /h = h:\), when asking for the absolute unix path with -au, cygpath doubles the / between the drive letter and the first directory of the path. /h echo Home | cygpath -au -f - /h//Home /h echo Home | cygpath -aw -f - h:\Home This does not happen when one is not in the root directory of the drive. /h cd Home /h/Home echo cartoons | cygpath -au -f - /h/Home/cartoons /h/Home echo cartoons | cygpath -aw -f - h:\Home\cartoons This does not happen when /h cd .. /h echo Home\\cartoons | cygpath -au -f - /h//Home/cartoons /h echo Home/cartoons | cygpath -aw -f - h:\Home\cartoons This is with cygwin 1.5, everything up to date. Note that this also happens on C:. Cygwin is in c:\\cygwin. Not much is going to be done about this now. This seems to work fine on Cygwin 1.7. cgf -- 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: Long file names not working in cygwin-1.7.0-48
On Fri, May 29, 2009 at 12:27:57PM -0700, jpa wrote: Thanks for testing. I can't tell what's different about my cwrsync config so I strace'd a test mkdir with a period using a 1.7.0-48 and snapshot cygwin dll and looked for differences. I found several differences where a \ was at the end of some lines where it wasn't in the successfull pass. I wasn't asking for strace output. If I had asked for it, I would not have asked you to use your judgement to snip it because no one EVER finds the right things to snip or provides the right information at first. This was no exception. Again, if you can show me how to duplicate the problem in a standard cygwin installation with just the new snapshot, I'll look into it. cgf -- 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.0-48: [BUG] Passing characters above 128 from bash command line
Hi Alexey, Thanks for explaining the UTF8 changes in cygwin 1.7. However, the decision to use UTF-8 for the C locale is questionable. It seems to me that it would be much safer to use the SYSTEM DEFAULT code page (ie. the return value of the system GetACP() function) for CYGWIN instead, ensuring compatibility for the large class native Windows applications that are non-Unicode, non-CodePage aware. Reading the original mailing list threads now, it seems like Corinna Vinschen also mentioned this using the system code page[1]. I tried to dig through the various mails in that thread didn't find any good objection to it. The only bug here is that the arguments are truncated instead of using some kind of a replacement character, is it related to some posix complience, like with wprintf? I think it's very bad that changing LANG can result in a truncated *command line*, that has nothing to do with printf. The printf in the code was just for testing. The HUGE bug is that the application gets the WRONG NUMBER OF ARGUMENTS. 1. http://www.mail-archive.com/cygwin@cygwin.com/msg96843.html Regards, -Edward Alexey Borzenkov wrote: On Fri, May 29, 2009 at 8:22 PM, Edward Lam edw...@sidefx.com wrote: I think there is still a bug here? I set LANG=C, then shouldn't be just NOT doing any encoding, thus work? If I do this on Linux, it works. If I use a cygwin compiled app, it also works. On Linux, internally, system uses multibyte strings (it is encoding agnostic even), but on Windows, system uses unicode strings, so cygwin has to decode your byte sequences somehow to pass them to non-cygwin processes as unicode (the fact that cygwin now understands unicode is a huge plus to me). In earlier discussions it was decided that cygwin C locale should use utf-8 encoding, because file system internally uses unicode it's the safest default to represent all possible filenames, etc. In previous cygwin versions, your byte sequences were just silently converted using your system's codepage (by the system itself, even), so if you want the old behavior you should set LANG=en_US.CP1252. The only bug here is that the arguments are truncated instead of using some kind of a replacement character, is it related to some posix complience, like with wprintf? -- 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/ -- 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: Long file names not working in cygwin-1.7.0-48
Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com wrote in message news:20090529194839.gc28...@ednor.casa.cgf.cx... On Fri, May 29, 2009 at 12:27:57PM -0700, jpa wrote: Thanks for testing. I can't tell what's different about my cwrsync config so I strace'd a test mkdir with a period using a 1.7.0-48 and snapshot cygwin dll and looked for differences. I found several differences where a \ was at the end of some lines where it wasn't in the successfull pass. I wasn't asking for strace output. If I had asked for it, I would not have asked you to use your judgement to snip it because no one EVER finds the right things to snip or provides the right information at first. This was no exception. Again, if you can show me how to duplicate the problem in a standard cygwin installation with just the new snapshot, I'll look into it. cgf Sorry. Understood. So I installed a vanilla Cygwin using setup v2.625 onto the machine that was giving me problems. administra...@gmisrvdr02 ~ $ cd /tmp administra...@gmisrvdr02 /tmp $ mkdir .test mkdir: cannot create directory `.test': No such file or directory administra...@gmisrvdr02 /tmp $ Cygcheck Cygwin Configuration Diagnostics Current System Time: Fri May 29 13:25:20 2009 Windows 2003 Server R2 Ver 5.2 Build 3790 Service Pack 2 Running in Terminal Service session Path: C:\Perl\site\bin C:\Perl\bin C:\Program Files\Windows Resource Kits\Tools\ C:\Program Files\Common Files\Pervasive Software Shared\pvswcore D:\ProHome\Timberline\SHARED\ C:\PVSW\BIN C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Files\Citrix\System32\Citrix\IMA C:\Program Files\Citrix\System32\Citrix\IMA\Subsystems C:\WINDOWS\System32\Citrix\IMA C:\Program Files\Citrix\system32 C:\Program Files\Common Files\Citrix\System32\ C:\Program Files\Common Files\Crystal Decisions\2.5\bin C:\Program Files\MySQL\MySQL Server 5.0\bin Output from C:\cygwin\bin\id.exe (nontsec) UID: 10500(Administrator) GID: 10513(Domain Users) 0(root) 544(Administrators) 545(Users) 10513(Domain Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 10500(Administrator) GID: 10513(Domain Users) 0(root) 544(Administrators) 545(Users) 10513(Domain Users) SysDir: C:\WINDOWS\system32 WinDir: C:\Documents and Settings\Administrator\WINDOWS Path = 'C:\Perl\site\bin;C:\Perl\bin;C:\Program Files\Windows Resource Kits\Tools\;C:\Program Files\Common Files\Pervasive Software Shared\pvswcore;D:\ProHome\Timberline\SHARED\;C:\PVSW\BIN;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Citrix\System32\Citrix\IMA;C:\Program Files\Citrix\System32\Citrix\IMA\Subsystems;C:\WINDOWS\System32\Citrix\IMA;C:\Program Files\Citrix\system32;C:\Program Files\Common Files\Citrix\System32\;C:\Program Files\Common Files\Crystal Decisions\2.5\bin;C:\Program Files\MySQL\MySQL Server 5.0\bin' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' APPDATA = 'C:\Documents and Settings\Administrator\Application Data' CLASSPATH = 'C:\PVSW\bin\pvjdbc2x.jar;C:\PVSW\bin\pvjdbc2.jar;C:\PVSW\bin\jpscs.jar;C:\PVSW\BIN\PVJDBC2X.JAR;C:\PVSW\BIN\PVJDBC2.JAR' CLIENTNAME = 'HOME-PC' ClusterLog = 'C:\WINDOWS\Cluster\cluster.log' CommonProgramFiles = 'C:\Program Files\Common Files' COMPUTERNAME = 'GMISRVDR02' ComSpec = 'C:\WINDOWS\system32\cmd.exe' FP_NO_HOST_CHECK = 'NO' HOMEDRIVE = 'C:' HOMEPATH = '\Documents and Settings\Administrator' LOGONSERVER = '\\GMISRVDR01' NUMBER_OF_PROCESSORS = '1' OS = 'Windows_NT' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = 'x86' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 2 Stepping 8, GenuineIntel' PROCESSOR_LEVEL = '15' PROCESSOR_REVISION = '0208' ProgramFiles = 'C:\Program Files' PROMPT = '$P$G' SESSIONNAME = 'RDP-Tcp#10' SystemDrive = 'C:' SystemRoot = 'C:\WINDOWS' TEMP = 'C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp' TMP = 'C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp' USERDNSDOMAIN = 'GEONERCO.COM' USERDOMAIN = 'GEONERCO' USERNAME = 'Administrator' USERPROFILE = 'C:\Documents and Settings\Administrator' VSL = 'C:\PVSW\\bin' windir = 'C:\WINDOWS' HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'C:\cygwin' obcaseinsensitive set to 1 a: fd N/AN/A c: hd NTFS 20481Mb 57% CP CS UN PA FC d: hd NTFS 36860Mb 58% CP CS UN PA FC Accounting e: cd N/AN/A f: hd NTFS204797Mb 81% CP CS UN PA FC Data h: net NTFS 36860Mb
Re: Long file names not working in cygwin-1.7.0-48
On Fri, May 29, 2009 at 03:48:39PM -0400, Christopher Faylor wrote: On Fri, May 29, 2009 at 12:27:57PM -0700, jpa wrote: Thanks for testing. I can't tell what's different about my cwrsync config so I strace'd a test mkdir with a period using a 1.7.0-48 and snapshot cygwin dll and looked for differences. I found several differences where a \ was at the end of some lines where it wasn't in the successfull pass. I wasn't asking for strace output. If I had asked for it, I would not have asked you to use your judgement to snip it because no one EVER finds the right things to snip or provides the right information at first. This was no exception. Again, if you can show me how to duplicate the problem in a standard cygwin installation with just the new snapshot, I'll look into it. I took a look at my late night patches and saw a couple of potential problems so I rewrote things and created a new snapshot. Please let me know if that works any better. I still can't duplicate your reported behavior however. cgf -- 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.0-48: [BUG] Passing characters above 128 from bash command line
On Sat, May 30, 2009 at 12:10 AM, Edward Lam edw...@sidefx.com wrote: Thanks for explaining the UTF8 changes in cygwin 1.7. However, the decision to use UTF-8 for the C locale is questionable. Not at all, because utf-8, as far as I understand, is used for communication with the system in this context, and does not force anything to the application. Most modern unixes use utf-8 nowadays, it means that even if you have a C locale your terminal outputs text in utf-8, your input is utf-8, your filenames are utf-8 (well, not really, but the rest of the system sees them that way). Same stuff here, except that launching non-cygwin processes is communication with the system as well, and it needs conversion. And where is conversion there is always possible loss of data. One way or the other. It seems to me that it would be much safer to use the SYSTEM DEFAULT code page (ie. the return value of the system GetACP() function) for CYGWIN instead, ensuring compatibility for the large class native Windows applications that are non-Unicode, non-CodePage aware. It might be safe for you, but not for other people. If you have a Russian default codepage and ever need to work with chineese/japanese filenames and cygwin uses default codepage for filesystem operations (as in 1.5 right now), then you are really screwed. In my opinion utf-8 is a silver bullet here, and I'm very glad it went that way. I think it's very bad that changing LANG can result in a truncated *command line*, that has nothing to do with printf. The printf in the code was just for testing. The HUGE bug is that the application gets the WRONG NUMBER OF ARGUMENTS. No, the bug is not that it gets wrong number of arguments. In fact, Windows has no concept of arguments, only C runtime does, which parses the command line. If command line is truncated, then C runtime will have missing arguments when it tries to parse it. I mentioned wprintf because recently I was wondering why mkpasswd/mkgroup had a strange truncating behavior with russian usernames and it turned out that wprintf, when it can't encode some characters, stops right there and returns an error code. But, honesly, who ever checks return codes from printf? Here might be something similar. When constructing command line some function is called and can't encode some character, returns error status, but it's never checked, and you get truncated command line. And btw, I'm not cygwin developer here, I'm just a speculating user right now, because I haven't been searching this problem in the code. -- 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: Long file names not working in cygwin-1.7.0-48
Christopher Faylor cgf-use-the-mailinglist-ple...@cygwin.com wrote in message news:20090529202951.ga2...@ednor.casa.cgf.cx... On Fri, May 29, 2009 at 03:48:39PM -0400, Christopher Faylor wrote: On Fri, May 29, 2009 at 12:27:57PM -0700, jpa wrote: Thanks for testing. I can't tell what's different about my cwrsync config so I strace'd a test mkdir with a period using a 1.7.0-48 and snapshot cygwin dll and looked for differences. I found several differences where a \ was at the end of some lines where it wasn't in the successfull pass. I wasn't asking for strace output. If I had asked for it, I would not have asked you to use your judgement to snip it because no one EVER finds the right things to snip or provides the right information at first. This was no exception. Again, if you can show me how to duplicate the problem in a standard cygwin installation with just the new snapshot, I'll look into it. I took a look at my late night patches and saw a couple of potential problems so I rewrote things and created a new snapshot. Please let me know if that works any better. I still can't duplicate your reported behavior however. cgf Thank you so much for working through this with me as it now works with the 20090529 snapshot. -- 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: R: [1.7] does LD_PRELOAD support more than 1 dll ?
--- Ven 29/5/09, Christopher Faylor ha scritto: Da: Christopher Faylor Oggetto: Re: R: [1.7] does LD_PRELOAD support more than 1 dll ? A: cygwin Data: Venerdì 29 maggio 2009, 18:01 On Fri, May 29, 2009 at 05:02:01PM +0100, Dave Korn wrote: Christopher Faylor wrote: On Fri, May 29, 2009 at 09:34:36AM +, Marco Atzeri wrote: It seems that cygwin does not accept the space as separator in LD_PRELOAD as other systems And lets just all take a moment of silence for a second to see if we can discern why that might be. The ubiquity of paths containing spaces on windows file systems? Yes, I probably never should have done it though since it isn't compatible with Linux. cgf May I suggest a small note in the documentation ? Just to help the next one to not fall in the same problem. :-) Further question, which are the limitation of the LD_PRELOAD implementation in cygwin ? Octave is built around 3 dlls cygcheck src/octave.exe C:\cygwin2\bin\cygoctinterp.dll C:\cygwin2\bin\cygcruft.dll [snip] C:\cygwin2\bin\cygoctave.dll [snip] on the other systems for the make check the program is called with LD_PRELOAD=$liboctinterp $liboctave $libcruft \ OCTAVE_SITE_INITFILE=$top_srcdir/scripts/startup/main-rcfile \ LD_LIBRARY_PATH=$builddir/src:$builddir/liboctave:$builddir/libcruft:$LD_LIBRARY_PATH \ exec $driver $builddir/src/octave --no-init-path --path=$LOADPATH --imag e-path=$IMAGEPATH --doc-cache-file=$DOCFILE --info-file=$INFOFILE $@ I replaced the space with : and now the program is loaded but on the tests I obtained mainly a long list of: src/DLD-FUNCTIONS/chol.cc .. 3 [main] sh 4032 C:\cygwin2\bin\sh.exe: *** fatal error - error while loading shared libraries: /pub/cygports/octave/octave-3.2.0-rc4_build/src/cygoctinterp.dll: cannot open shared object file: No such process the same if I try to plot plot(x,x) 3 [main] sh 4052 C:\cygwin2\bin\sh.exe: *** fatal error - error while loading shared libraries: /pub/cygports/octave/octave-3.2.0-rc4_build/src/cygoctinterp.dll: cannot open shared object file: No such process 3 [main] gnuplot 1640 C:\cygwin2\bin\gnuplot.exe: *** fatal error - error while loading shared libraries: /pub/cygports/octave/octave-3.2.0-rc4_build/src/cygoctinterp.dll: cannot open shared object file: No such process so it seems that the LD_PRELOAD is not working well in case of fork. It is not a critical issue as I already have implemented a workaround. For the test I remove the LD_PRELOAD definition and add the build directories in front of the PATH. I am just curious to understand the limitation. Thanks Marco -- 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.0-48: [BUG] Passing characters above 128 from bash command line
Alexey Borzenkov wrote: It might be safe for you, but not for other people. If you have a Russian default codepage and ever need to work with chineese/japanese filenames and cygwin uses default codepage for filesystem operations (as in 1.5 right now), then you are really screwed. In my opinion utf-8 is a silver bullet here, and I'm very glad it went that way. I must be missing something here. Suppose you have a default Russian code page, with LANG unset (ie. cygwin 1.7 uses UTF-8). Now, if you're using any non-Unicode, non-CodePage aware, native application to create a Russian filename, isn't Windows going to convert the filename from the Russian code page into UTF-16 for storage in NTFS? If that is the case, and then you do an ls from cygwin 1.7, aren't you going to get the wrong filename displayed? ie. interoperability with non-Unicode, non-CodePage aware native applications will be broken for you too with the current default cygwin 1.7 behaviour. Or is this, not a case that you care about and you *only* use cygwin applications? Regards, -Edward Alexey Borzenkov wrote: On Sat, May 30, 2009 at 12:10 AM, Edward Lam edw...@sidefx.com wrote: Thanks for explaining the UTF8 changes in cygwin 1.7. However, the decision to use UTF-8 for the C locale is questionable. Not at all, because utf-8, as far as I understand, is used for communication with the system in this context, and does not force anything to the application. Most modern unixes use utf-8 nowadays, it means that even if you have a C locale your terminal outputs text in utf-8, your input is utf-8, your filenames are utf-8 (well, not really, but the rest of the system sees them that way). Same stuff here, except that launching non-cygwin processes is communication with the system as well, and it needs conversion. And where is conversion there is always possible loss of data. One way or the other. It seems to me that it would be much safer to use the SYSTEM DEFAULT code page (ie. the return value of the system GetACP() function) for CYGWIN instead, ensuring compatibility for the large class native Windows applications that are non-Unicode, non-CodePage aware. It might be safe for you, but not for other people. If you have a Russian default codepage and ever need to work with chineese/japanese filenames and cygwin uses default codepage for filesystem operations (as in 1.5 right now), then you are really screwed. In my opinion utf-8 is a silver bullet here, and I'm very glad it went that way. I think it's very bad that changing LANG can result in a truncated *command line*, that has nothing to do with printf. The printf in the code was just for testing. The HUGE bug is that the application gets the WRONG NUMBER OF ARGUMENTS. No, the bug is not that it gets wrong number of arguments. In fact, Windows has no concept of arguments, only C runtime does, which parses the command line. If command line is truncated, then C runtime will have missing arguments when it tries to parse it. I mentioned wprintf because recently I was wondering why mkpasswd/mkgroup had a strange truncating behavior with russian usernames and it turned out that wprintf, when it can't encode some characters, stops right there and returns an error code. But, honesly, who ever checks return codes from printf? Here might be something similar. When constructing command line some function is called and can't encode some character, returns error status, but it's never checked, and you get truncated command line. And btw, I'm not cygwin developer here, I'm just a speculating user right now, because I haven't been searching this problem in the code. -- 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/ -- 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.0-48: [BUG] Passing characters above 128 from bash command line
Alexey Borzenkov wrote:
No, the bug is not that it gets wrong number of arguments. In fact,
Windows has no concept of arguments, only C runtime does, which parses
the command line. If command line is truncated, then C runtime will
have missing arguments when it tries to parse it.
Sorry, I had meant to comment on this previously but hit send too soon.
I think the problem I'm running into is:
- I give cygwin 1.7's bash a string that is in my system default code page.
- cygwin 1.7 thinks the string is actually UTF-8 and tries to convert it
as UTF-8 into UTF-16, resulting in a truncated command line that is
passed to child process.
Here's some more investigation:
$ cat bug.c
#include stdio.h
int wmain(int argc, wchar_t *argv[], wchar_t *envp[])
{
int i;
for (i = 0; i argc; i++)
wprintf(L%d: %s\n, i, argv[i]);
return 0;
}
... and compiled using MSVC
$ ./bug arg1 before `cat copyright.txt` after arg3
0: E:\cygwin1.7\tmp\bug.exe
1: arg1
2: before
So note that even when I'm seems to be an UNICODE-AWARE child process,
I'm still getting a truncated command line. In fact, call
GetCommandLineW() directly seems to give a truncated command line
as well.
Regards,
-Edward
Alexey Borzenkov wrote:
On Sat, May 30, 2009 at 12:10 AM, Edward Lam edw...@sidefx.com wrote:
Thanks for explaining the UTF8 changes in cygwin 1.7. However, the decision
to use UTF-8 for the C locale is questionable.
Not at all, because utf-8, as far as I understand, is used for
communication with the system in this context, and does not force
anything to the application. Most modern unixes use utf-8 nowadays, it
means that even if you have a C locale your terminal outputs text in
utf-8, your input is utf-8, your filenames are utf-8 (well, not
really, but the rest of the system sees them that way). Same stuff
here, except that launching non-cygwin processes is communication with
the system as well, and it needs conversion. And where is conversion
there is always possible loss of data. One way or the other.
It seems to me that it would be much safer to use the SYSTEM DEFAULT code
page (ie. the return value of the system GetACP() function) for CYGWIN
instead, ensuring compatibility for the large class native Windows
applications that are non-Unicode, non-CodePage aware.
It might be safe for you, but not for other people. If you have a
Russian default codepage and ever need to work with chineese/japanese
filenames and cygwin uses default codepage for filesystem operations
(as in 1.5 right now), then you are really screwed. In my opinion
utf-8 is a silver bullet here, and I'm very glad it went that way.
I think it's very bad that changing LANG can result in a truncated *command
line*, that has nothing to do with printf. The printf in the code was just
for testing. The HUGE bug is that the application gets the WRONG NUMBER OF
ARGUMENTS.
No, the bug is not that it gets wrong number of arguments. In fact,
Windows has no concept of arguments, only C runtime does, which parses
the command line. If command line is truncated, then C runtime will
have missing arguments when it tries to parse it.
I mentioned wprintf because recently I was wondering why
mkpasswd/mkgroup had a strange truncating behavior with russian
usernames and it turned out that wprintf, when it can't encode some
characters, stops right there and returns an error code. But, honesly,
who ever checks return codes from printf?
Here might be something similar. When constructing command line some
function is called and can't encode some character, returns error
status, but it's never checked, and you get truncated command line.
And btw, I'm not cygwin developer here, I'm just a speculating user
right now, because I haven't been searching this problem in the code.
--
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/
--
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.0-48: [BUG] Passing characters above 128 from bash command line
On Sat, May 30, 2009 at 1:04 AM, Edward Lam edw...@sidefx.com wrote: Alexey Borzenkov wrote: It might be safe for you, but not for other people. If you have a Russian default codepage and ever need to work with chineese/japanese filenames and cygwin uses default codepage for filesystem operations (as in 1.5 right now), then you are really screwed. In my opinion utf-8 is a silver bullet here, and I'm very glad it went that way. I must be missing something here. Suppose you have a default Russian code page, with LANG unset (ie. cygwin 1.7 uses UTF-8). Now, if you're using any non-Unicode, non-CodePage aware, native application to create a Russian filename, isn't Windows going to convert the filename from the Russian code page into UTF-16 for storage in NTFS? If that is the case, and then you do an ls from cygwin 1.7, aren't you going to get the wrong filename displayed? ie. interoperability with non-Unicode, non-CodePage aware native applications will be broken for you too with the current default cygwin 1.7 behaviour. Or is this, not a case that you care about and you *only* use cygwin applications? No, it is precisely that I care about both ends of interoperability. Here is a hypotetical situation: for filename in `ls`; do someprogram $filename done Here, when I use russian Windows and I don't have LANG set (or when I have LANG=en_US.UTF-8), filename will be utf-8 multibyte string. So both, russian and european/chinese/japanese filenames will be valid. Now there are three possibilities: 1) someprogram is a cygwin application, then it must be that $filename will be passed as is, without any conversions 2) someprogram is a unicode application, then it will have a correct unicode argument 3) someprogram is an ansi application, then Windows (cygwin has nothing to do with it) will convert its unicode arguments to system's codepage (cp1251 for Russian) and any character that can't be encoded will be replaced with question marks. This is solely someprogram's fault and cygwin has nothing to do with it. All I'm trying to say is that on Windows (since WinNT) arguments are always in unicode. It just so happens that when ansi applications call other ansi applications with a sequence of bytes, it first gets converted to unicode, then back to ansi, and you get the same sequence of bytes. But the arguments are always characters, not bytes. -- 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.0-48: [BUG] Passing characters above 128 from bash command line
On Sat, May 30, 2009 at 1:21 AM, Edward Lam edw...@sidefx.com wrote: Here's some more investigation: [...] So note that even when I'm seems to be an UNICODE-AWARE child process, I'm still getting a truncated command line. In fact, call GetCommandLineW() directly seems to give a truncated command line as well. And again, you must have misunderstood me. In my opinion: truncation is a bug (should use replacement character, or fail exec altogether), expecting utf-8 is not (if you tried to cat your copyright.txt on a Linux box that uses utf-8, what would you expect to see on the screen?) -- 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: emacs -nw keypad, tpu-edt.el, and C-h
Actually, this holy war can be bypassed, without sacrificing Emacs correctly working on a console. What the console should send for that is the Backspace function key. Makes sense to me. Andy, is there any reason all cygwin terminals shouldn't do this (including mintty)? This already happens under X, and users would then have consistent behavior. What is the Backspace function key, i.e. what character sequence does that correspond to? I've had a look at the emacs source. The Windows console variant of emacs uses low-level console I/O, namely the ReadConsoleInput() function. This delivers a stream of so-called input events, rather than a stream of characters like the high-level console functions. Also see here for the distinction: http://msdn.microsoft.com/en-us/library/ms683497(VS.85).aspx One type of input event is a key event, which tells you exactly what key was pressed and which modifiers are down. Emacs translates that directly into its internal keyboard representation such as Backspace, thereby indeed bypassing the whole question of how keys should be represented in a character stream. Unix terminals are character devices though, sp terminal emulators have to encode keyboard events as sequences of characters, as that's what terminal applications expect to get. The terminal version of emacs then translates those into its internal representation. Now of course if emacs can translate low-level console I/O as it sees fit, then the Cygwin DLL could also be able to translate Backspace into ^? characters rather than ^H, in CYGWIN=tty mode anyway. So I had a look at fhandler_console.cc. It already uses ReadConsoleInput(), so mapping from VK_BACK to ^? might be fairly straightforward actually. I guess Cygwin 1.7 will be the last chance for quite a while to make such a change, so is this something that should be considered? A bit of googling tells me that Redhat Linux actually decided to follow the Debian guidelines many years ago and used ^? ever since, apart from a little wobble in Fedora Core 3. Andy -- 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: R: [1.7] does LD_PRELOAD support more than 1 dll ?
Marco Atzeri wrote: May I suggest a small note in the documentation ? Just to help the next one to not fall in the same problem. :-) PTC and all that... if you want a hand with the English grammar/spelling, ask me offlist. so it seems that the LD_PRELOAD is not working well in case of fork. Did you export it? That might make a difference if the shell is involved. cheers, DaveK -- 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: emacs -nw keypad, tpu-edt.el, and C-h
On 5/29/2009 5:59 PM, Andy Koppe wrote: Now of course if emacs can translate low-level console I/O as it sees fit, then the Cygwin DLL could also be able to translate Backspace into ^? characters rather than ^H, in CYGWIN=tty mode anyway. So I had a look at fhandler_console.cc. It already uses ReadConsoleInput(), so mapping from VK_BACK to ^? might be fairly straightforward actually. I guess Cygwin 1.7 will be the last chance for quite a while to make such a change, so is this something that should be considered? A bit of googling tells me that Redhat Linux actually decided to follow the Debian guidelines many years ago and used ^? ever since, apart from a little wobble in Fedora Core 3. As I user, I certainly favor having cygwin behave the same as Debian and Redhat. The change would also provide consistency between Cygwin's terminals and Cygwin/X. Is there any downside? Ken -- 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/
[ANNOUNCEMENT] [1.7] Updated: git-1.6.3.1-1, git{k,-gui,-completion,-svn}-1.6.3.1-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A new release of git, 1.6.3.1-1, has been uploaded to the cygwin 1.7 release area. This replaces 1.6.2.4-2 as current. NEWS: = This is a new upstream major release. I'm attaching the release notes; see also the package documentation in /usr/share/doc/git/. When compiled out of the box, the upstream git maintainers cater to older cygwin releases, and intentionally disable certain features that have been reported on their mailing list, even though they work with the latest cygwin. Therefore, this build turns those features back on. However, it means that this version does assume that you are not using FAT or FAT32 to hold your repositories, since they do not store file permissions very accurately. DESCRIPTION: Git is popular version control system designed to handle very large projects with speed and efficiency; it is used mainly for various open source projects, most notably the Linux kernel. Git falls in the category of distributed source code management tools, similar to e.g. GNU Arch or Monotone (or BitKeeper in the proprietary world). Every Git working directory is a full-fledged repository with full revision tracking capabilities, not dependent on network access or a central server. UPDATE: === To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'git', 'gitk', 'git-gui', and/or 'git-completion' from the 'Devel' category. DOWNLOAD: = Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. - -- Eric Blake volunteer cygwin git maintainer CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkogq24ACgkQ84KuGfSFAYDHmwCePH489RWycumRDdvurATFwjO+ 2AcAoJuwmbQwaH+5eOHASgNEc9zP7Zsh =Sh8Q -END PGP SIGNATURE- GIT v1.6.3.1 Release Notes == Fixes since v1.6.3 -- * git checkout -b new-branch with a staged change in the index incorrectly primed the in-index cache-tree, resulting a wrong tree object to be written out of the index. This is a grave regression since the last 1.6.2.X maintenance release. GIT v1.6.3 Release Notes With the next major release, git push into a branch that is currently checked out will be refused by default. You can choose what should happen upon such a push by setting the configuration variable receive.denyCurrentBranch in the receiving repository. To ease the transition plan, the receiving repository of such a push running this release will issue a big warning when the configuration variable is missing. Please refer to: http://git.or.cz/gitwiki/GitFaq#non-bare http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 for more details on the reason why this change is needed and the transition plan. For a similar reason, git push $there :$killed to delete the branch $killed in a remote repository $there, if $killed branch is the current branch pointed at by its HEAD, gets a large warning. You can choose what should happen upon such a push by setting the configuration variable receive.denyDeleteCurrent in the receiving repository. When the user does not tell git push what to push, it has always pushed matching refs. For some people it is unexpected, and a new configuration variable push.default has been introduced to allow changing a different default behaviour. To advertise the new feature, a big warning is issued if this is not configured and a git push without arguments is attempted. Updates since v1.6.2 (subsystems) * various git-svn updates. * git-gui updates, including an update to Russian translation, and a fix to an infinite loop when showing an empty diff. * gitk updates, including an update to Russian translation and improved Windows support. (performance) * many uses of lstat(2) in the codepath for git checkout have been optimized
Re: R: [1.7] does LD_PRELOAD support more than 1 dll ?
--- Sab 30/5/09, Dave Korn ha scritto: Da: Dave Korn Oggetto: Re: R: [1.7] does LD_PRELOAD support more than 1 dll ? A: cygwin@cygwin.com Data: Sabato 30 maggio 2009, 03:07 Marco Atzeri wrote: May I suggest a small note in the documentation ? Just to help the next one to not fall in the same problem. :-) PTC and all that... if you want a hand with the English grammar/spelling, ask me offlist. so it seems that the LD_PRELOAD is not working well in case of fork. Did you export it? That might make a difference if the shell is involved. cheers, DaveK Hi Dave, also exporting all the 3 variables in the script does make no difference export PATH=$builddir/src:$builddir/liboctave:$builddir/libcruft:$PATH export LD_PRELOAD=$liboctinterp:$liboctave:$libcruft export LD_LIBRARY_PATH=$builddir/src:$builddir/liboctave:$builddir/libcruft:$LD_LIBRARY_PATH OCTAVE_SITE_INITFILE=$top_srcdir/scripts/startup/main-rcfile \ exec $driver $builddir/src/octave --no-init-path --path=$LOADPATH --image-path=$IMAGEPATH --doc-cache-file=$DOCFILE --info-file=$INFOFILE $@ 5 [main] sh 3964 C:\cygwin2\bin\sh.exe: *** fatal error - error while loading shared libraries: /pub/cygports/octave/octave-3.2.0-rc4_build/src/cygoctinterp.dll: cannot open shared object file: No such process Regards Marco -- 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: R: [1.7] does LD_PRELOAD support more than 1 dll ?
On Sat, May 30, 2009 at 04:55:12AM +, Marco Atzeri wrote:
--- Sab 30/5/09, Dave Korn ha scritto:
Da: Dave Korn
Oggetto: Re: R: [1.7] does LD_PRELOAD support more than 1 dll ?
A: cygwin@cygwin.com
Data: Sabato 30 maggio 2009, 03:07
Marco Atzeri wrote:
May I suggest a small note in the documentation ?
Just to help the next one to not fall in the same
problem.
:-)
? PTC and all that... if you want a hand with the
English grammar/spelling,
ask me offlist.
so it seems that the LD_PRELOAD is not working well
in case of fork.
? Did you export it?? That might make a
difference if the shell is involved.
? ? cheers,
? ? ? DaveK
Hi Dave,
also exporting all the 3 variables in the script
does make no difference
export PATH=$builddir/src:$builddir/liboctave:$builddir/libcruft:$PATH
export LD_PRELOAD=$liboctinterp:$liboctave:$libcruft
export
LD_LIBRARY_PATH=$builddir/src:$builddir/liboctave:$builddir/libcruft:$LD_LIBRARY_PATH
OCTAVE_SITE_INITFILE=$top_srcdir/scripts/startup/main-rcfile \
exec $driver $builddir/src/octave --no-init-path --path=$LOADPATH
--image-path=$IMAGEPATH --doc-cache-file=$DOCFILE --info-file=$INFOFILE
$@
5 [main] sh 3964 C:\cygwin2\bin\sh.exe: *** fatal error - error while
loading shared libraries:
/pub/cygports/octave/octave-3.2.0-rc4_build/src/cygoctinterp.dll: cannot open
shared object file: No such process
From the source:
if (!LoadLibraryW (lib.get_wide_win32_path (libname)))
{
__seterrno ();
api_fatal (error while loading shared libraries: %s:
cannot open shared object file: %s, p,
strerror (get_errno ()));
}
No such process == ESRCH == PROC_NOT_FOUND
cgf
--
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: emacs -nw keypad, tpu-edt.el, and C-h
On Fri, May 29, 2009 at 10:59:21PM +0100, Andy Koppe wrote: Now of course if emacs can translate low-level console I/O as it sees fit, then the Cygwin DLL could also be able to translate Backspace into ^? characters rather than ^H, in CYGWIN=tty mode anyway. So I had a look at fhandler_console.cc. It already uses ReadConsoleInput(), so mapping from VK_BACK to ^? might be fairly straightforward actually. And a patch would have been appreciated... However, I have made the change to Cygwin to translate backspace to ^?. It will be in the next snapshot. cgf -- 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] Updated: git-1.6.3.1-1, git{k,-gui,-completion,-svn}-1.6.3.1-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A new release of git, 1.6.3.1-1, has been uploaded to the cygwin 1.7 release area. This replaces 1.6.2.4-2 as current. NEWS: = This is a new upstream major release. I'm attaching the release notes; see also the package documentation in /usr/share/doc/git/. When compiled out of the box, the upstream git maintainers cater to older cygwin releases, and intentionally disable certain features that have been reported on their mailing list, even though they work with the latest cygwin. Therefore, this build turns those features back on. However, it means that this version does assume that you are not using FAT or FAT32 to hold your repositories, since they do not store file permissions very accurately. DESCRIPTION: Git is popular version control system designed to handle very large projects with speed and efficiency; it is used mainly for various open source projects, most notably the Linux kernel. Git falls in the category of distributed source code management tools, similar to e.g. GNU Arch or Monotone (or BitKeeper in the proprietary world). Every Git working directory is a full-fledged repository with full revision tracking capabilities, not dependent on network access or a central server. UPDATE: === To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Save it and run setup, answer the questions and pick up 'git', 'gitk', 'git-gui', and/or 'git-completion' from the 'Devel' category. DOWNLOAD: = Note that downloads from sources.redhat.com (aka cygwin.com) aren't allowed due to bandwidth limitations. This means that you will need to find a mirror which has this update, please choose the one nearest to you: http://cygwin.com/mirrors.html QUESTIONS: == If you want to make a point or ask a question the Cygwin mailing list is the appropriate place. - -- Eric Blake volunteer cygwin git maintainer CYGWIN-ANNOUNCE UNSUBSCRIBE INFO: = To unsubscribe to the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkogq24ACgkQ84KuGfSFAYDHmwCePH489RWycumRDdvurATFwjO+ 2AcAoJuwmbQwaH+5eOHASgNEc9zP7Zsh =Sh8Q -END PGP SIGNATURE- GIT v1.6.3.1 Release Notes == Fixes since v1.6.3 -- * git checkout -b new-branch with a staged change in the index incorrectly primed the in-index cache-tree, resulting a wrong tree object to be written out of the index. This is a grave regression since the last 1.6.2.X maintenance release. GIT v1.6.3 Release Notes With the next major release, git push into a branch that is currently checked out will be refused by default. You can choose what should happen upon such a push by setting the configuration variable receive.denyCurrentBranch in the receiving repository. To ease the transition plan, the receiving repository of such a push running this release will issue a big warning when the configuration variable is missing. Please refer to: http://git.or.cz/gitwiki/GitFaq#non-bare http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 for more details on the reason why this change is needed and the transition plan. For a similar reason, git push $there :$killed to delete the branch $killed in a remote repository $there, if $killed branch is the current branch pointed at by its HEAD, gets a large warning. You can choose what should happen upon such a push by setting the configuration variable receive.denyDeleteCurrent in the receiving repository. When the user does not tell git push what to push, it has always pushed matching refs. For some people it is unexpected, and a new configuration variable push.default has been introduced to allow changing a different default behaviour. To advertise the new feature, a big warning is issued if this is not configured and a git push without arguments is attempted. Updates since v1.6.2 (subsystems) * various git-svn updates. * git-gui updates, including an update to Russian translation, and a fix to an infinite loop when showing an empty diff. * gitk updates, including an update to Russian translation and improved Windows support. (performance) * many uses of lstat(2) in the codepath for git checkout have been optimized
