1.7.10: cygpath -p wide char path lists not yet supported - cygcheck.out (0/1)
$ cygpath -u 'C:\WINDOWS' /win/c/WINDOWS $ cygpath -pu 'C:\WINDOWS' 15 [main] cygpath 5076 C:\cygwin\bin\cygpath.exe: *** fatal error - wide char path lists not yet supported Hangup -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.10: cygpath -p wide char path lists not yet supported - cygcheck.out (0/1)
On Feb 8 12:22, Andrew Schulman wrote: $ cygpath -u 'C:\WINDOWS' /win/c/WINDOWS $ cygpath -pu 'C:\WINDOWS' 15 [main] cygpath 5076 C:\cygwin\bin\cygpath.exe: *** fatal error - wide char path lists not yet supported Hangup Try `uname -r' Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.10: cygpath -p wide char path lists not yet supported - cygcheck.out (0/1)
On Feb 8 12:22, Andrew Schulman wrote: $ cygpath -u 'C:\WINDOWS' /win/c/WINDOWS $ cygpath -pu 'C:\WINDOWS' 15 [main] cygpath 5076 C:\cygwin\bin\cygpath.exe: *** fatal error - wide char path lists not yet supported Hangup Try `uname -r' Erf, thanks. I had updated to 1.7.10, but as you guessed, uname -r said 1.7.9. BTW, after restarting all Cygwin process, uname -r still said 1.7.9. So I rebooted; still 1.7.9. So I looked in c:\cygwin\bin, and found that cygwin1.dll was still version 1.7.9, but there was also cygwin1.dll.new, version 1.7.10. So I removed cygwin1.dll and renamed cygwin1.dll.new, and now I'm running 1.7.10. Is that the expected behavior for setup? I assume that I had left some Cygwin processes running when I updated to 1.7.10. I don't remember setup warning me about replacing files in use, although maybe it did and I forgot. But I thought the problem was supposed to take care of itself after a reboot - I don't remember ever encountering cygwin1.dll.new before. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.10: cygpath -p wide char path lists not yet supported - cygcheck.out (0/1)
On Feb 8 13:16, Andrew Schulman wrote: On Feb 8 12:22, Andrew Schulman wrote: $ cygpath -u 'C:\WINDOWS' /win/c/WINDOWS $ cygpath -pu 'C:\WINDOWS' 15 [main] cygpath 5076 C:\cygwin\bin\cygpath.exe: *** fatal error - wide char path lists not yet supported Hangup Try `uname -r' Erf, thanks. I had updated to 1.7.10, but as you guessed, uname -r said 1.7.9. BTW, after restarting all Cygwin process, uname -r still said 1.7.9. So I rebooted; still 1.7.9. So I looked in c:\cygwin\bin, and found that cygwin1.dll was still version 1.7.9, but there was also cygwin1.dll.new, version 1.7.10. So I removed cygwin1.dll and renamed cygwin1.dll.new, and now I'm running 1.7.10. Is that the expected behavior for setup? I assume that I had left some Cygwin processes running when I updated to 1.7.10. I don't remember setup warning me about replacing files in use, although maybe it did and I forgot. But I thought the problem was supposed to take care of itself after a reboot - I don't remember ever encountering cygwin1.dll.new before. THe fact that you have a .new file shows that setup tried to replace the file after reboot. However, the Win32 functionality, MoveFileEx with MOVEFILE_DELAY_UNTIL_REBOOT | MOVEFILE_REPLACE_EXISTING flags apparently doesn't work under all circumstances. See, for instance, http://social.msdn.microsoft.com/Search/en-US?query=PendingFileRenameOperations for more information. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7.10: cygpath -p wide char path lists not yet supported - cygcheck.out (0/1)
THe fact that you have a .new file shows that setup tried to replace the file after reboot. However, the Win32 functionality, MoveFileEx with MOVEFILE_DELAY_UNTIL_REBOOT | MOVEFILE_REPLACE_EXISTING flags apparently doesn't work under all circumstances. See, for instance, http://social.msdn.microsoft.com/Search/en-US?query=PendingFileRenameOperations for more information. Thank you. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Not yet supported (was: emacs shell)
On 12 December 2007 18:40, Marc Girod wrote: And the error in the terminal from where emacs was started is (several times each code, as if at random, with different address ranges): 379530601 [main] emacs 4964 child_copy: linked dll data write copy failed, 0x33B000..0x33B440, done 0, windows pid 4080, Win32 error 487 570693374 [main] emacs 4964 child_copy: linked dll data write copy failed, 0x94..0x940240, done 0, windows pid 4080, Win32 error 998 OK. I get now the same kind of errors again with startx: 326 [main] xterm 4680 child_copy: linked dll data write copy failed, 0x869000..0x86CF40, done 0, windows pid 5416, Win32 error 87 xterm: Error 29, errno 11: Resource temporarily unavailable Reason: spawn: fork() failed xinit: Resource temporarily unavailable (errno 11): can't send HUP to process group 4680 ...and I found such hits in older messages in the archive, with other variants of Windows, in conjunction to inconsistent versions of cygwin1.dll. That's one thing that can cause it. Another cause is interference from system-call-hooking software such as anti-virus and firewalls. What the error message is trying to tell you is that during the fork operation, it has been unable to duplicate an area of memory from the parent process into the child process. Since it's a requirement that fork() create child processes identically laid out to their parents, this is a fatal situation. I checked there is no such problem now. Good. The next things to try would be running a rebaseall[*], and checking the BLODA[**]. But running 'cygcheck -s', I got into: Windows Longhorn/Vista (not yet supported!) Ver 6.0 Build 6000 Yes, Vista isn't well supported; not a lot of the list members even have it! cheers, DaveK [*] - less -c /usr/share/doc/Cygwin/rebase-2.4.3.README [**] - http://cygwin.com/ml/cygwin-talk/2007-q4/msg00026.html -- Can't think of a witty .sigline today -- 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/
Not yet supported (was: emacs shell)
Hi... Marc Girod wrote: And the error in the terminal from where emacs was started is (several times each code, as if at random, with different address ranges): 379530601 [main] emacs 4964 child_copy: linked dll data write copy failed, 0x33B000..0x33B440, done 0, windows pid 4080, Win32 error 487 570693374 [main] emacs 4964 child_copy: linked dll data write copy failed, 0x94..0x940240, done 0, windows pid 4080, Win32 error 998 OK. I get now the same kind of errors again with startx: 326 [main] xterm 4680 child_copy: linked dll data write copy failed, 0x869000..0x86CF40, done 0, windows pid 5416, Win32 error 87 xterm: Error 29, errno 11: Resource temporarily unavailable Reason: spawn: fork() failed xinit: Resource temporarily unavailable (errno 11): can't send HUP to process group 4680 ...and I found such hits in older messages in the archive, with other variants of Windows, in conjunction to inconsistent versions of cygwin1.dll. I checked there is no such problem now. But running 'cygcheck -s', I got into: Windows Longhorn/Vista (not yet supported!) Ver 6.0 Build 6000 Marc -- View this message in context: http://www.nabble.com/tetex-on-Vista-tp14108577p14301296.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Not yet supported
On 12/12/2007 2:37 PM, Marc Girod wrote: After this, startx started at least twice in a row, but emacs didn't show up. I.e. started, but no window!... This is an old problem. You have to reinstall libncurses7 to get emacs back. See http://sourceware.org/ml/cygwin/2006-10/msg00540.html 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: Not yet supported (was: emacs shell)
Thanks... Dave Korn wrote: Good. The next things to try would be running a rebaseall[*], and checking the BLODA[**]. rebaseall ran without any output. The only BLODA I can recognize is McAfee anti-virus. There is an integrated WebCam on the laptop, but no Logitech labelled process in the task manager output. After this, startx started at least twice in a row, but emacs didn't show up. I.e. started, but no window!... I ran the ash rebaseall with my normal account, not as Administrator...? Marc -- View this message in context: http://www.nabble.com/tetex-on-Vista-tp14108577p14302172.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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/
emacs (was: Not yet supported)
Hi Ken, Ken Brown-6 wrote: This is an old problem. You have to reinstall libncurses7 to get emacs back. See http://sourceware.org/ml/cygwin/2006-10/msg00540.html Indeed. And my shell started in emacs too... Gee... but I am short of problems! Thanks! Marc -- View this message in context: http://www.nabble.com/tetex-on-Vista-tp14108577p14303136.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Not yet supported [Attn emacs maintainer]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ken Brown on 12/12/2007 12:44 PM: This is an old problem. You have to reinstall libncurses7 to get emacs back. See http://sourceware.org/ml/cygwin/2006-10/msg00540.html So, is emacs 22.1 ever going to be promoted to current? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYIms84KuGfSFAYARAr+HAJwMhIedtOPWCPE3g+eEBiFgPCcLvwCfe3kt JVL+UdbvNsSisIQtSd5db18= =IZ9J -END PGP SIGNATURE- -- 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: Not yet supported [Attn emacs maintainer]
On 12/12/2007 8:23 PM, Eric Blake wrote: So, is emacs 22.1 ever going to be promoted to current? Unfortunately, there are serious problems with the (experimental) emacs 22.1 package, as I and at least one other person reported last July when it was released. See especially http://cygwin.com/ml/cygwin/2007-07/msg00773.html http://cygwin.com/ml/cygwin/2007-07/msg00799.html http://cygwin.com/ml/cygwin/2007-07/msg00844.html I haven't heard whether there's been any progress resolving this. 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: Not yet supported [Attn emacs maintainer]
Dear All, I am trying to use xemacs. After installation of cygwin, I used once but later it doesn't work. it gives this error: temacs can only be run in -batch mode what do you suggest? thanks regards -- 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/
