Re: Slowdown after update on Win32 (XP Home)
Michael Ludwig schrieb am 30.10.2010 um 15:55 (+0200): Michael Ludwig schrieb am 07.10.2010 um 00:27 (+0200): SZABÓ Gergely schrieb am 06.10.2010 um 23:30 (+0200): please see this thread (test scripts included): http://cygwin.com/ml/cygwin/2010-09/msg00871.html Thanks, Gabor - I saw your thread, which reinforces my belief that it is a Cygwin issue. I don't think any more the slow process creation (fork) I'm seeing is a Cygwin problem. A Makefile for ActiveState Perl also takes an eternity to run. The delay appears to be caused by time-consuming process creation. I can only confirm this. Process creation is much slower with 1.7.7 than it was with 1.5.25. The fork script runs 300% slower on my XP box. Another possibility would be a recent Microsoft update. Am I hallucinating when I think that 100% true Windows utilities like IPCONFIG, ROUTE and NET are also slower in launching? These Windows utilities also take time to launch. All processes, once running, do *not* appear slow; they just take time to get started. What can I do at the Windows or Cygwin level to find the cause of this slowdown? Using Sysinternals procmon.exe I found out that the cause for the slowdown was a virus hooking into the CreateProcess/AppCertDlls mechanism, which, of course, I didn't know about. What could cause a process creation slowdown on Win32 and how can I determine it? http://stackoverflow.com/questions/4354445/ AppCertDlls: Process creation slowdown on Win32 caused by virus -- Michael Ludwig -- 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: Slowdown after update on Win32 (XP Home)
Michael Ludwig schrieb am 07.10.2010 um 00:27 (+0200): SZABÓ Gergely schrieb am 06.10.2010 um 23:30 (+0200): please see this thread (test scripts included): http://cygwin.com/ml/cygwin/2010-09/msg00871.html Thanks, Gabor - I saw your thread, which reinforces my belief that it is a Cygwin issue. I don't think any more the slow process creation (fork) I'm seeing is a Cygwin problem. A Makefile for ActiveState Perl also takes an eternity to run. The delay appears to be caused by time-consuming process creation. I can only confirm this. Process creation is much slower with 1.7.7 than it was with 1.5.25. The fork script runs 300% slower on my XP box. Another possibility would be a recent Microsoft update. Am I hallucinating when I think that 100% true Windows utilities like IPCONFIG, ROUTE and NET are also slower in launching? These Windows utilities also take time to launch. All processes, once running, do *not* appear slow; they just take time to get started. What can I do at the Windows or Cygwin level to find the cause of this slowdown? -- Michael Ludwig -- 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: Win7 64bit, why so slow?
Gerrit P. Haase schrieb am 19.10.2010 um 22:50 (+0200): Also, you might also be running into this problem: http://cygwin.com/ml/cygwin/2010-05/msg00190.html No bash completion here: $ time bash -i -c echo real0m0.312s user0m0.015s sys 0m0.076s And this wouldn't cause sh, m4 or perl scripts to run that slow like here, like all the autotools are incredible slow for me. I'm clueless as to whether it is related or not, but I've been enjoying a similarly bad slowdown on Win32 for about the last four weeks. I wouldn't say that it renders Cygwin totally useless, but it certainly does so for certain tasks which spawn a lot of processes, which is where i think the problem lies. Slowdown after update on Win32 (XP Home) http://cygwin.com/ml/cygwin/2010-09/msg00893.html But it might be a different one than what you are dealing with. Turning on -x on the shell clearly shows that the slowdown is due to process creation. Completion is out of the way, as I uninstalled it. Security software is something I don't have. bash is noticeable slower with completion activated, this I can confirm: $ time bash -i -c echo real0m1.731s user0m0.325s sys 0m0.699s $ time bash -i -c echo real0m8.025s user0m1.404s sys 0m0.794s $ time bash -i -c echo real0m7.910s user0m1.467s sys 0m0.779s $ time bash -i -c echo real0m6.560s user0m1.169s sys 0m0.734s -- Michael Ludwig -- 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: Slowdown after update on Win32 (XP Home)
Larry Hall (Cygwin) schrieb am 03.10.2010 um 20:50 (-0400): On 10/1/2010 8:08 PM, Michael Ludwig wrote: Larry Hall (Cygwin) schrieb am 30.09.2010 um 20:38 (-0400): My WAG is you're suffering from changes in the new version of bash_completion. If you don't use this, uninstall it. Would bash completion account for several simultaneous bash processes on login as described? Anyway, I uninstalled it, and the problem persists. OK. I see it points out ZoneAlarm. That's worth uninstalling and trying again. Sorry for replying late, and thanks for your help. I uninstalled that ZoneAlarm crapware several years ago. Looks like the uninstall routine forgot to remove one registry key. You should also look at virus and other security software you have installed. Uninstall them 1 by 1 to see if you can pinpoint the problem. I don't run any security software other than Windows Firewall. Multiple simultaneous bash processes trying to start up, that's what I keep observing. Process performance is as usual, but process creation is horribly slow, probably because it is frequently failing before it can be accomplished. -- Michael Ludwig -- 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: Slowdown after update on Win32 (XP Home)
SZABÓ Gergely schrieb am 06.10.2010 um 23:30 (+0200): please see this thread (test scripts included): http://cygwin.com/ml/cygwin/2010-09/msg00871.html Thanks, Gabor - I saw your thread, which reinforces my belief that it is a Cygwin issue. I can only confirm this. Process creation is much slower with 1.7.7 than it was with 1.5.25. The fork script runs 300% slower on my XP box. Another possibility would be a recent Microsoft update. Am I hallucinating when I think that 100% true Windows utilities like IPCONFIG, ROUTE and NET are also slower in launching? But on the other hand, Marco Atzeri could not confirm this on his XP box. I'm sure it's all about time slowing down in the vicinity of black holes... A computational maelstrom, a processing quicksand. -- Michael Ludwig -- 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: Slowdown after update on Win32 (XP Home)
Michael Ludwig schrieb am 07.10.2010 um 00:27 (+0200): SZABÓ Gergely schrieb am 06.10.2010 um 23:30 (+0200): please see this thread (test scripts included): http://cygwin.com/ml/cygwin/2010-09/msg00871.html Thanks, Gabor - ... Thanks *Gergely*! Michael -- 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
Slowdown after update on Win32 (XP Home)
I'm seeing a painfully noticeable slowdown on my system. I must have contracted this slowdown last week. My Cygwin is up to date as of now, October 1st, 01:00 CET Starting a MinTTY (or rxvt, for that matter) from the icon I've placed in the start menu does not take the usual two or three seconds, but may take as much as a whole minute. During this startup attempt phase, I can see various bash processes with different PIDs bubbling to the top in taskmgr. I've seen up to three of them at the same time when my MinTTY was trying to start as the first Cygwin process, so there should have been no other bash processes around. This is Win32, XP Home SP3. I hope this description is helpful in debugging this issue. -- Michael Ludwig -- 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: Slowdown after update on Win32 (XP Home)
Michael Ludwig schrieb am 01.10.2010 um 01:19 (+0200): I'm seeing a painfully noticeable slowdown on my system. I must have contracted this slowdown last week. My Cygwin is up to date as of now, October 1st, 01:00 CET For a bit more precision, here's an excerpt from $(cygcheck -s): Cygwin DLL version info: DLL version: 1.7.7 DLL epoch: 19 DLL old termios: 5 DLL malloc env: 28 Cygwin conv: 181 API major: 0 API minor: 230 Shared data: 5 DLL identifier: cygwin1 Mount registry: 3 Cygwin registry name: Cygwin Program options name: Program Options Installations name: Installations Cygdrive default prefix: Build date: Shared id: cygwin1S5 -- Michael Ludwig -- 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: How to get a script file to use bash and ssh
PaulHR schrieb am 02.09.2010 um 12:10 (-0700): I want to create script files that are not bound to my user id. I want to create over 20 different scripts files, one for each server I manage. I have uploaded keys to each server. So all I should have to is enter is the ssh command Sounds like you want to explore what options ~/.ssh/config has: Host s22 HostName server-22.bla.rz User superadmin Then type: ssh s22 Same mechanism available for PuTTY. -- Michael Ludwig -- 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: Building Mutt: configure: invalid value of canonical build
Matthias Andree schrieb am 01.09.2010 um 02:19 (+0200): It's your problem if you don't like the answers. Not a problem at all, actually. :-) Your fix attempts break the build system further, meaning that: if you touch config.sub, you create a blank canonicalization script, so don't complain about canonicalization errors or other malfunctions -- you triggered those yourself. You chose the blue pill, asking for blitheness, joy, and ignorance. No, I *am* ignorant considering autoconf/automake, and I'm aware of it. And I was aware my touchy fix might create new problems, that's why I included it in my report so more knowledgeable people (like you) could point it out. \,,,/ (o o) --oOOo-(_)-oOOo-- framing excellent advice - So to sell you a faint clue of what the red pill might have provided if you had so chosen: a *real* config.sub is what should be doing the canonicalization -- a blank script won't achieve that. automake --add-missing (which is called as part of ./prepare) is what would install a set of real config.sub, install-sh, missing, and related scripts. Thanks! It worked exactly as you described! I wasn't aware there was a step to be done before `configure'. The question of if the mutt distribution is incomplete is a distinct one - and the command line you showed on Monday works fine on a mutt HEAD checkout from the Mercurial repo if you follow Csaba's advice; however you can usually just omit --build=... and the auto* built stuff will call config.guess to figure. Right. I imagined something in the source package was missing because I don't usually have to specify --build. Is that `prepare' script a standard step in autoconf? Or is it a custom feature of either Mutt or Cygwin or something else? One of these days I'll finally get around to sort out the GNU build suite stuff. -- Michael Ludwig -- 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: Building Mutt: configure: invalid value of canonical build
Reid Thompson schrieb am 31.08.2010 um 23:26 (-0400): Download the mutt 1.5.20 source from the mutt website.. it configures fine for me (had to add some dev libs, etc) Thanks. Same here for the Cygwin source package after the `prepare' step. It's just about knowing which strings to pull. -- Michael Ludwig -- 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: Building Mutt: configure: invalid value of canonical build
Matthias Andree schrieb am 31.08.2010 um 00:58 (+0200): On 30.08.2010 23:52, Michael Ludwig wrote: The mutt mail reader shipping with Cygwin does not have SMTP enabled, which I'd like to give a try. So I tried to build mutt, but encountered problems. [... long whine about non-working build snipped ...] Whatever pills you've taken to discern lengthiness and whininess, I'd definitely recommend you stop taking them, especially when driving or writing email. [ irrelevant advice snipped ] -- Michael Ludwig -- 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: Building Mutt: configure: invalid value of canonical build
Csaba Raduly schrieb am 31.08.2010 um 09:17 (+0200): On Mon, Aug 30, 2010 at 11:52 PM, Michael Ludwig wrote: It is only after receiving an error because of the script's failure to guess the build system that I added the --build option to configure. But obviously I didn't fill in a correct value. What should I try? Try: i686-pc-cygwin This is what gcc -v reports. Thanks, I didn't know that. Unfortunately, the outcome is identical: \,,,/ (o o) --oOOo-(_)-oOOo-- cd /usr/src cp -r mutt-1.5.20-1/ mutt-1.5.20-1.milu # copy mutt source package cd mutt-1.5.20-1.milu touch install-sh# else you'll get an error touch config.sub# ditto ./configure --build=i686-pc-cygwin --prefix=/usr/local/mutt \ --enable-imap --enable-smtp --enable-hcache --with-regex --with-ssl # configure output snipped checking build system type... configure: error: invalid value of canonical build - Might there be something wrong with the source package for mutt? I remember building mutt from another Cygwin source package without any problems. -- Michael Ludwig -- 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
Building Mutt: configure: invalid value of canonical build
The mutt mail reader shipping with Cygwin does not have SMTP enabled, which I'd like to give a try. So I tried to build mutt, but encountered problems. The machine is 64-Bit PC running Win7/64/Pro, and Cygwin, of course. I have both gcc 3 and 4 installed. ./configure --prefix=/usr/local/mutt --build=i686-pc \ --enable-imap --enable-smtp --enable-hcache --with-regex --with-ssl Note that I specified a (wrong) --build option, but read on and see below. Independently of that --build option, I got the following error: configure: error: cannot run /bin/sh ./config.sub The solution is easy: touch config.sub Got the same for install-sh, by the way. Now on to the main error. Trying again the same configure line. \,,,/ (o o) --oOOo-(_)-oOOo-- checking whether build environment is sane... yes /bin/sh: /usr/src/mutt-1.5.20-1.milu/orig/missing: No such file or directory configure: WARNING: `missing' script is too old or missing ... [don't know if the above is a problem] ... checking build system type... configure: error: invalid value of canonical build - It is only after receiving an error because of the script's failure to guess the build system that I added the --build option to configure. But obviously I didn't fill in a correct value. What should I try? -- Michael Ludwig -- 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: Moving Cygwin directory safe?
Christopher Faylor schrieb am 29.06.2010 um 10:44 (-0400): Actually, the point I was trying to make was that you should never have to use regedit to make Cygwin work correctly. There is no reason to add anything if your installation is working correctly. It would have worked correctly if you had left the registry alone but, since you didn't, there was no reason to restore the first directory. I didn't want the cygwin archives to have advice which suggested that regedit was necessary to move the DLL. Got it. Thanks! -- Michael Ludwig -- 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: Moving Cygwin directory safe?
Corinna Vinschen schrieb am 29.06.2010 um 10:25 (+0200): On Jun 28 22:57, Michael Ludwig wrote: Actually, while it's not necessary, it makes sense to keep the entries under the installations key intact. They are generated the first time a Cygwin DLL is used. They are useful to find out where Cygwin DLLs are (or were) installed on your system. Including the 64 bit hex value which forms the names of the entries, it allows to diagnose problems which potentially arise from parallel Cygwin installations. If you move your installation to another path, a new entry will be generated. Indeed - I now have two entries under the Installations key. To please the Gods, I restored the first one to the original directory. Thanks! To be complete on this issue and include one detail I omitted from my list: Explorer failed to copy some files (SSH keys), which belonged to the user NT-AUTORITÄT\SYSTEM and could not be read by my admin user, so I had to do the following: subinacl /file C:\cygwin\etc\ssh* /setowner=michael subinacl /file C:\cygwin\etc\ssh*key /grant=michael=R That's a fine case for either using Cygwin tools to create the new installation tree (cpio, for instance), or to use robocopy with the /B option. Thanks once more - I didn't know about this apparently very useful tool. Explorer keeps disappointing me by cowardly aborting long-running copy operations on the first sign of trouble. -- Michael Ludwig -- 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: Moving Cygwin directory safe?
Christopher Faylor schrieb am 27.06.2010 um 15:01 (-0400): On Sun, Jun 27, 2010 at 03:37:26PM +0200, Michael Ludwig wrote: I copied C:\cygwin to T: instead of reinstalling. Here's a list of things I had to fix (or fixed preemptively): * fixed the above registry settings ...which was not necessary. Yes, you hinted at that it might not be, but I didn't know whether these keys are left-overs from by-gone versions, or derived from some other setting, or whatnot, so not knowing whether I could delete them I thought I might as well adapt them to reflect the new values, To be complete on this issue and include one detail I omitted from my list: Explorer failed to copy some files (SSH keys), which belonged to the user NT-AUTORITÄT\SYSTEM and could not be read by my admin user, so I had to do the following: subinacl /file C:\cygwin\etc\ssh* /setowner=michael subinacl /file C:\cygwin\etc\ssh*key /grant=michael=R (This is XP Home, which does not come with the real security tab in Explorer, so you have to resort to supplementary tools.) -- Michael Ludwig -- 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: Moving Cygwin directory safe?
Andrey Repin schrieb am 27.06.2010 um 05:10 (+0400): Greetings, Michael Ludwig! My Cygwin resides under C:\cygwin (plus G:\cygvar for packages), but as both C: and G: are nearly full, I'd like to move the Cygwin folders to partition T: which has plenty of space left. Is this safe or are there things such as registry entries that will prevent Cygwin from working properly, or even deconfigure or corrupt my installation? There is, but nothing that can really damage your installation. However, to be on a safe side, you better reinstall it fresh in the new place, copying over your personal settings. Look into HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin to deal with recorded installations. Thanks! That's what I have under that key: \,,,/ (o o) --oOOo-(_)-oOOo-- Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin] [HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations] c5e39b7a9d22bafb=\\??\\C:\\cygwin [HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options] [HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup] rootdir=C:\\cygwin - Looks like I should be able to fix those paths after moving C:\cygwin. Sorry for my terrible english... Извините for my terrible русский :-) (In other words, I think you can safely drop that line.) -- Michael Ludwig -- 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: Moving Cygwin directory safe?
Michael Ludwig schrieb am 27.06.2010 um 11:55 (+0200): [HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations] c5e39b7a9d22bafb=\\??\\C:\\cygwin [HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options] [HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup] rootdir=C:\\cygwin - Looks like I should be able to fix those paths after moving C:\cygwin. I copied C:\cygwin to T: instead of reinstalling. Here's a list of things I had to fix (or fixed preemptively): * fixed the above registry settings * fix shortcuts to setup.exe/cygwin/rxvt/MinTTY in start menu: right-click and select Eigenschaften (properties) * edited T:\Cygwin\cygwin.bat to include correct paths * edited my Windows Vim configuration which sourced files from my Cygwin Vim configuration The root directory in setup.exe is displayed correctly. Seems to depend on the registry setting. The Local Package Directory path, however, which I copied from G:\CygVar to T:\CygVar, needs fixing. Maybe another registry setting someplace else. Haven't done any testing, but so far it seems to be working. -- Michael Ludwig -- 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: Moving Cygwin directory safe?
Steven Monai schrieb am 27.06.2010 um 09:55 (-0700): On 2010/06/27 6:37 AM, Michael Ludwig wrote: The root directory in setup.exe is displayed correctly. Seems to depend on the registry setting. The Local Package Directory path, however, which I copied from G:\CygVar to T:\CygVar, needs fixing. Maybe another registry setting someplace else. Have a look at the text file '/etc/setup/setup.rc'. It should contain a relevant setting named 'last-cache'. It does. Thanks! -- Michael Ludwig --- 4:1 gegen England !!! -- 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.5 NT-5.1: Mutt 1.5.20 Illegal instruction on Gmail IMAP Connection
Aidan McQuay schrieb am 23.06.2010 um 15:58 (+0200): Mutt was just updated, with the new version when I try to make a connection to gmail it gives me an Illegal instruction message and crashes. Not sure this is Cygwin-specific, so I'd rather report this on the mutt-users mailing list. http://www.mutt.org/mail-lists.html I had minor upgrade problems, too, and have quickly been helped there. Can't help you, though, as I've never used IMAP. -- Michael Ludwig -- 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
Moving Cygwin directory safe?
My Cygwin resides under C:\cygwin (plus G:\cygvar for packages), but as both C: and G: are nearly full, I'd like to move the Cygwin folders to partition T: which has plenty of space left. Is this safe or are there things such as registry entries that will prevent Cygwin from working properly, or even deconfigure or corrupt my installation? -- Michael Ludwig -- 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: 'cp' utility bug when dest-name.exe file exist.
Oleksandr Gavenko schrieb am 08.06.2010 um 16:47 (+0300): $ touch my.exe $ touch some-file $ cp some-file my cp: cannot create regular file `my': File exists $ cp -f some-file my cp: cannot create regular file `my': File exists Same happen ever in cmd.exe so this is not 'bash' fault. Here's a test script for further amusement. Bottom line is that cp and shell redirection do quite some unexpected and uncalled-for clobbering. That should probably be fixed. \,,,/ (o o) --oOOo-(_)-oOOo-- #!/bin/bash --verbose dirname=/tmp/tt$(date +%s) mkdir $dirname cd $dirname || exit $? touch eins.exe # create eins.exe ls -l echo 1 eins # clobbers eins.exe ls -l echo 22 zwei # create zwei cp zwei eins# refuses to create file (the OP's report) ls -l mv eins.exe eins# rename eins.exe to eins cp zwei eins# overwrites eins as expected ls -l rm eins # delete eins echo 1 eins.exe # recreate eins.exe ls -l mv zwei eins# creates eins, does not clobber eins.exe ls -l mv eins zwei# rename it back to zwei echo 222 ../zwei.exe # create file with extension cp ../zwei.exe .# clobbers file without exe extension ls -l echo zwei# clobbers file with exe extension ls -l cp ../zwei.exe zwei # refuses to create file ls -l mv ../zwei.exe zwei # creates zwei, does not clobber zwei.exe ls -l cp ../zwei .# clobbers file with exe extension ls -l - As for the general question, Windows and UNIX are very different, and Cygwin does a fantastic exe-magic job of bringing the two together, a great treat for those who want to, or have to, use both systems. Thanks for that! -- Michael Ludwig -- 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
Unicode/UTF-8 support (MinTTY) - ncursesw - Mutt, Vim
After having used rxvt without Unicode support for years, the other day I discovered MinTTY, which does support UTF-8 - very nice! The occasional Greek or Cyrillic letters showing up in mails will no longer be displayed as ? or ?? in the Mutt mail reader, I thought. Same story for editing with Vim. Not quite, though. There are display and editing problems in both programs. From reading, I believe this is due to their being linked to ncurses instead of ncursesw (w for wide characters), as shown by ldd: $ ldd $(which vim) | grep curses cygncurses-10.dll = /usr/bin/cygncurses-10.dll (0x6958) $ ldd $(which mutt) | grep curses cygncurses-8.dll = /usr/bin/cygncurses-8.dll (0x6c18) Is this assessment correct, and complete in that this is the defining reason for the display problems? The wide-character ncursesw was announced in January: This is the first official release of ncurses compiled to support wide characters, and can be installed simultaineously with the narrow ncurses package(s). http://www.mail-archive.com/cygwin-annou...@cygwin.com/msg03179.html It sounds like Unicode is the preferred way now: Actually, I'd prefer if people started using -I/usr/include/ncursesw and linking against the wide version of the library instead. http://sourceware.org/ml/cygwin/2010-05/msg00465.html People seem to have had success compiling Mutt with ncursesw: http://code.google.com/p/mintty/issues/detail?id=124 Are ncursesw versions of Vim and Mutt imminent? Or is it not going to happen anytime soon? -- Michael Ludwig -- 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: Unicode/UTF-8 support (MinTTY) - ncursesw - Mutt, Vim
Corinna Vinschen schrieb am 07.06.2010 um 12:40:43 (+0200): On Jun 7 11:23, Michael Ludwig wrote: Are ncursesw versions of Vim and Mutt imminent? Or is it not going to happen anytime soon? Thanks for the heads up. I'll build the next release of vim (there's a 7.3 release coming soon) against ncursesw. That's great! Thank you! As for Mutt, I downloaded the sources via Cygwin setup.exe and recompiled against ncursesw. As I couldn't find a suitable configure option, I had to edit the Makefile as follows to (1) enable ncursesw and (2) skip building the documentation (which would fail): \,,,/ (o o) --oOOo-(_)-oOOo-- diff Makefile Makefile.orig 164c164 CPPFLAGS = -I/usr/include/ncursesw -I$(top_srcdir)/intl -I$(includedir) --- CPPFLAGS = -I/usr/include/ncurses -I$(top_srcdir)/intl -I$(includedir) 208c208 MUTTLIBS = -lncursesw --- MUTTLIBS = -lncurses 283c283 SUBDIRS = m4 po intl contrib $(IMAP_SUBDIR) --- SUBDIRS = m4 po intl doc contrib $(IMAP_SUBDIR) - Text in Russian or Greek looks perfect now. Same for Mutt's internationalized messages in German, Russian, Greek. Отвечать по cyg...@cygwin.com? ([да]/нет): (Japanese, Korean and Chinese are another story, possibly on account of missing fonts.) Great job, ncursesw! I think just like Vim users, Mutt users would also appreciate Unicode support. -- Michael Ludwig -- 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: Unicode/UTF-8 support (MinTTY) - ncursesw - Mutt, Vim
Andy Koppe schrieb am 07.06.2010 um 12:14:20 (+0100): On 7 June 2010 11:40, Corinna Vinschen wrote: �I'll build the next release of vim (there's a 7.3 release coming soon) against ncursesw. Probably a good idea anyway, but as far as I can see, vim works fine with UTF-8 already. Michael, what are the issues you're seeing with vim? Are you using Cygwin 1.7? As you say, Vim works fine with UTF-8. It's just that until very recently, I've been using the rxvt terminal emulator, which lacks Unicode support; so Vim being compiled against ncurses (*without* wide characters) was a good match. Now that I'm switching to the MinTTY terminal, which supports Unicode/UTF-8, I need a Vim compiled against ncursesw (*with* wide characters) if my assessment of the situation is correct. -- Michael Ludwig -- 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: Unicode/UTF-8 support (MinTTY) - ncursesw - Mutt, Vim
Michael Ludwig schrieb am 07.06.2010 um 14:28 (+0200): As for Mutt, I downloaded the sources via Cygwin setup.exe and recompiled against ncursesw. As I couldn't find a suitable configure option, I had to edit the Makefile as follows to (1) enable ncursesw and (2) skip building the documentation (which would fail): To get the same behaviour as with the Cygwin binary Mutt, some more tweaking of configure flags or other stuff seems required. Two differences I've noted so far: * An error message repetition-operator operand invalid appears on startup for * instead of .* in folder-hook directives. * My built forgets about mailboxes it has seen so they're all flagged as containing new messages. As I said, it would be fine to have a binary Mutt compiled and linked against ncursesw with wide character support. -- Michael Ludwig -- 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: Unicode/UTF-8 support (MinTTY) - ncursesw - Mutt, Vim
Michael Ludwig schrieb am 07.06.2010 um 15:09 (+0200): To get the same behaviour as with the Cygwin binary Mutt, some more tweaking of configure flags or other stuff seems required. Two differences I've noted so far: * An error message repetition-operator operand invalid appears on startup for * instead of .* in folder-hook directives. Avoided by specifying --with-regex for the configure script. * My built forgets about mailboxes it has seen so they're all flagged as containing new messages. Solved by specifying --enable-buffy-size for the configure script. The Cygwin build has more stuff enabled (which I don't use). My configure line was: ./configure --prefix=/usr/local/muttw2 --with-regex --enable-buffy-size The feature and package sets of different builds can be compared by diffing the output of mutt -v and reading the output of configure --help. -- Michael Ludwig -- 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: Unicode/UTF-8 support (MinTTY) - ncursesw - Mutt, Vim
Andy Koppe schrieb am 07.06.2010 um 19:17 (+0100):
On 7 June 2010 13:44, Michael Ludwig wrote:
As you say, Vim works fine with UTF-8. It's just that until very
recently, I've been using the rxvt terminal emulator, which lacks
Unicode support; so Vim being compiled against ncurses (*without*
wide characters) was a good match.
Now that I'm switching to the MinTTY terminal, which supports
Unicode/UTF-8, I need a Vim compiled against ncursesw (*with*
wide characters) if my assessment of the situation is correct.
My assessment was incorrect.
If vim works fine with UTF-8 already, what does it matter which
ncurses it's linked against? I don't know vim's internals, but I'd
guess it works without ncursesw because it does its own screen
buffering and displaying, using ncurses only for accessing the
terminfo database.
I don't have much of an idea of what ncurses is actually used for,
nor how Unicode support works in Vim. I simply assessed the two
were somehow connected. :-)
The truth is rather trivial and refreshing. My ~/.vimrc contained
some hard-coded configuration for Latin1 on Cygwin (win32unix):
MiLu: Cygwin/rxvt kann nur Latin1.
if has('win32unix')
set termencoding=latin1
endif
That setting applied on a UTF-8 terminal garbled input, output and
display for non-ASCII characters. After eliminating that it all works
fine. Thanks for not letting my assessment pass!
--
Michael Ludwig
--
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
