Vim + windows clipboard
Hi, I'm working on a integrating vim with the windows clipboard. The approach I took was to reuse the win32 clipboard handling routines that are normally part of compiling vim for windows use. I know that it basically works for me (I don't do anything other than edit ASCII), but I don't know about all the other configurations, etc. I don't know what peoples preferences would be if I should try to get these changes part of vim, or a patch for cygwin, or if any else even cares. Any advice? Thanks, Frodak Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html
Re: Vim + windows clipboard
Frodak, le Sat 13 Jan 2007 08:51:29 -0800, a écrit : I know that it basically works for me (I don't do anything other than edit ASCII), but I don't know about all the other configurations, etc. I don't know what peoples preferences would be if I should try to get these changes part of vim, or a patch for cygwin, or if any else even cares. I think it should be part of vim, just like X clipboard support etc. are. Samuel
Re: CVS setup.exe crashes on Windows 2003 Server x64
Thrall, Bryan wrote: ... And in fact, disabling DEP for setup.exe fixes the problem. So, it looks like setup.exe is trying to execute some memory that Windows thinks it shouldn't be (the invalid this pointer, probably, but why then is it invalid at that point and valid after the segfault?). Setup.exe does contain some self-modifying code. It is in the file autoload.c, and deals with automatic loading of certain DLLs not present on all Windows versions. Glancing at it, it looks very 32-bit specific. It seems fairly miraculous that it works at all on LP64, actually, considering it casts pointers to int. Max. signature.asc Description: OpenPGP digital signature
Re: Vim + windows clipboard
On Jan 13 17:59, Samuel Thibault wrote: Frodak, le Sat 13 Jan 2007 08:51:29 -0800, a écrit : I know that it basically works for me (I don't do anything other than edit ASCII), but I don't know about all the other configurations, etc. I don't know what peoples preferences would be if I should try to get these changes part of vim, or a patch for cygwin, or if any else even cares. I think it should be part of vim, just like X clipboard support etc. are. Yep, this should definitely go upstream. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Xorg automatic keyboard layout.
Hi. As stated in your faq, if I find a keyboard layout that is not automaticly detected I should send it over to you guys. (--) winConfigKeyboard - Layout: 040F (040f) (EE) Keyboardlayout Icelandic (040F) is unknown This layout is 'is' layout, standard 105 keys layout. http://www.microsoft.com/globaldev/reference/keyboards.mspx you cant directly link to the icelandic keyboard, so you would have to choose it from a list to see the layout. Thank you. :) With regards, Sigurdur Gudbrandsson -- 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/
Cygwin X Server
I downloaded Cygwin the other day, and haven't been able to get it running. The first time I installed it, whenever I would run Cygwin.bat, the command shell would open up. However, it would immediately close. So I reinstalled Cygwin, and was able to get the bash shell to work. Then I tried to open the X-Server, however if I type startx into the Cygwin bash shell, it pauses for a moment. X-Server process starts taking up the remaining % of my CPU, and the bash shell says: -- $ startx waiting for X server to begin accepting connections . .. .. .. and the dots continue on forever until I have to kill the program. If I try running cygwin\usr\X11R6\bin\startxwin.bat it comes up with an error box, and gives me this text in the cygwin\temp\XWin.txt: - _XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created. (II) XF86Config is not supported (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel winAllocateFBShadowGDI - Creating DIB with width: 1280 height: 1024 depth: 32 winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 null screen fn ReparentWindow null screen fn RestackWindow InitQueue - Calling pthread_mutex_init InitQueue - pthread_mutex_init returned InitQueue - Calling pthread_cond_init InitQueue - pthread_cond_init returned winInitMultiWindowWM - Hello winInitMultiWindowWM - Calling pthread_mutex_lock () winMultiWindowXMsgProc - Hello winMultiWindowXMsgProc - Calling pthread_mutex_lock () MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: 0409 (0409) (--) Using preset keyboard for English (USA) (409), type 4 (--) 3 mouse buttons found Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from list! Fatal server error: could not open default font 'fixed' winDeinitMultiWindowWM - Noting shutdown in progress --- I have tried reinstalling X11 fonts, and even X11 multiple times, from multiple mirrors, even all of cygwin. But it never seems to work. I would greatly appreciate any feedback that may help me fix this problem, I was looking forward to getting to use cygwin, and it frustrates me that I have spent a couple hours on this and it doesn't work. Thanks for you time. --Josh Gramoll -- 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/
src/winsup/cygwin ChangeLog glob.cc
CVSROOT:/cvs/src Module name:src Branch: cr-0x5f1 Changes by: [EMAIL PROTECTED] 2007-01-13 10:20:41 Modified files: winsup/cygwin : ChangeLog glob.cc Log message: * glob.cc: Update copyright notice with latest from FreeBSD. (glob0): Use correct type for c variable to propagate previously detected protection. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srconly_with_tag=cr-0x5f1r1=1.3582.2.21r2=1.3582.2.22 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/glob.cc.diff?cvsroot=srconly_with_tag=cr-0x5f1r1=1.1.2.1r2=1.1.2.2
src/winsup/cygwin ChangeLog syscalls.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2007-01-13 20:56:01 Modified files: winsup/cygwin : ChangeLog syscalls.cc Log message: * syscalls.cc (unlink_nt): Don't move files to recycle bin which are not in use. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.3711r2=1.3712 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc.diff?cvsroot=srcr1=1.424r2=1.425
Re: 1.7.0 CVS mmap failure
On Thu, Jan 11, 2007 at 10:46:48AM +0100, Corinna Vinschen wrote: This works on my machine now. So previously why was the former method failing, do you think? Er... haven't we discussed this at great lengths in this thread? Yes, but did we ever establish a reason that was actually solid in foundation? The reason I ask again what may be obvious is because of the still-present ambiguity back here: That's not visible in the above strace. Since the pagesize is supposed to be == allocation granularity == 64K, but file mappings are aligned to the next page boundary beyond EOF (sigh), Cygwin tries to accomodate the expectations of the application by appending an anonymous mapping to fill the whole mapping up to 64K. In the failing case this should still work, since 0x7fff7000 + 0x9000 (36864 dec) == 0x8000, so the mapping should fit into the usual 2 Gig address space. Why Windows fails to do it, I have no idea. The error code 487 means invalid address which might mean already taken address, but that's not visible in the strace. To figure that out would require to add a bit of VirtualQuery code to mmap and add appropriate debug output. Actually this shows a problem in the mmap implementation with respect to MEM_TOP_DOWN. I think, what mmap should actually do is to create a lightweight MAP_RESERVE anonymous mapping of the whole requested mapping size, then close it again and then reopen it with the address it got in this first try. This would probably ensure that the subsequent two mapping will work. However, it's not quite clear if that really would help since the above *should* have worked to the best of my knowledge. Corinna The real question I have is why was what *should* have worked, not working? -cl -- 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 CVS mmap failure
On Jan 13 00:22, Christopher Layne wrote: The real question I have is why was what *should* have worked, not working? That has been answered immediately in the replies: http://cygwin.com/ml/cygwin/2007-01/msg00093.html http://cygwin.com/ml/cygwin/2007-01/msg00095.html http://cygwin.com/ml/cygwin/2007-01/msg00097.html Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: ssh-host-config patch
On Jan 12 17:54, Miguel A. Figueroa-Villanueva wrote: Hello Everyone, When configuring sshd host with the ssh-host-config script I got errors from the chown commands at the end of the script. The reason is that my /etc/group file sets S-1-5-32-544 to 0 not 544 (my passwd/group files are printed below). I think the following patch is appropriate so that this case can be handled. Thanks for the patch, but there's a reason for using 544 here. It's the right gid when using mkgroup and it should be unambiguous, even if the group file has multiple entries for the admins group. I like to have the 0 as group, too, but I have left the 544 entry in so that scripts relying on the gid still work. When you use `ls -l' you still get the gid 0 this way: $ grep S-1-5-32-544 /etc/group root:S-1-5-32-544:0: admins:S-1-5-32-544:544: Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: gcc: installation problem, cannot exec 'cc1'
Hello, The file crt2.o is present in /usr/lib/mingw. But the error remains the same. [EMAIL PROTECTED] ~ $ gcc -mno-cygwin hello.c /usr/bin/ld: crt2.o: No such file: No such file or directory collect2: ld returned 1 exit status I also found that I get another error if I compile the program from within the directory /usr/lib/mingw .See this: [EMAIL PROTECTED] /usr/lib/mingw $ gcc -mno-cygwin ~/hello.c /usr/bin/ld: cannot find -lmingw32 collect2: ld returned 1 exit status ~ Thomas On 1/12/07, Larry Hall (Cygwin) [EMAIL PROTECTED] wrote: Thomas Antony wrote: Hello, Come to think of it, I had removed the read only stuff when it drove me nuts with silly errors when I tried to delete or move files. But not on C drive. Anyway, I removed those links using the script you said and reinstalled. Now ls lists them correctly $ ls -l /usr/lib/gcc/i686-pc-mingw32/3.4.4/ total 1234 lrwxrwxrwx 1 Tom None 34 Jan 12 09:34 cc1.exe - ../../i686-pc-cygwin/3.4 .4/cc1.exe lrwxrwxrwx 1 Tom None 38 Jan 12 09:32 cc1plus.exe - ../../i686-pc-cygwin /3.4.4/cc1plus.exe lrwxrwxrwx 1 Tom None 39 Jan 12 09:34 collect2.exe - ../../i686-pc-cygwi n/3.4.4/collect2.exe -rwxr-xr-x 1 Tom None 412 May 24 2005 crtbegin.o -rwxr-xr-x 1 Tom None 492 May 24 2005 crtend.o drwxrwxr--+ 2 Tom Users 0 Jan 12 09:32 debug drwxrwxr--+ 3 Tom Users 0 Jan 12 09:34 include drwxrwxr--+ 3 Tom Users 0 Jan 12 09:34 install-tools -rwxr-xr-x 1 Tom None52594 May 24 2005 libgcc.a -rwxr-xr-x 1 Tom None 9772 May 24 2005 libgcov.a -rwx--+ 1 Tom None 1063604 May 24 2005 libstdc++.a -rwx--+ 1 Tom None 685 May 24 2005 libstdc++.la -rwx--+ 1 Tom None 116074 May 24 2005 libsupc++.a -rwx--+ 1 Tom None 685 May 24 2005 libsupc++.la lrwxrwxrwx 1 Tom None 32 Jan 12 09:34 specs - ../../i686-pc-cygwin/3.4.4 /specs But now, while compiling I get the error $ gcc -mno-cygwin -o hello hello.c /usr/bin/ld: crt2.o: No such file: No such file or directory collect2: ld returned 1 exit status ?? Now what? Is crt2.o in /usr/lib/mingw? Does it look OK? -- 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/ -- 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 CVS mmap failure
On Sat, Jan 13, 2007 at 11:25:08AM +0100, Corinna Vinschen wrote: On Jan 13 00:22, Christopher Layne wrote: The real question I have is why was what *should* have worked, not working? That has been answered immediately in the replies: http://cygwin.com/ml/cygwin/2007-01/msg00093.html http://cygwin.com/ml/cygwin/2007-01/msg00095.html http://cygwin.com/ml/cygwin/2007-01/msg00097.html Also, thanks for working with us to fix it - it's appreciated. -cl -- 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: gcc: installation problem, cannot exec 'cc1'
On 13 January 2007 11:26, Thomas Antony wrote: Hello, The file crt2.o is present in /usr/lib/mingw. But the error remains the same. [EMAIL PROTECTED] ~ $ gcc -mno-cygwin hello.c /usr/bin/ld: crt2.o: No such file: No such file or directory collect2: ld returned 1 exit status I also found that I get another error if I compile the program from within the directory /usr/lib/mingw .See this: [EMAIL PROTECTED] /usr/lib/mingw $ gcc -mno-cygwin ~/hello.c /usr/bin/ld: cannot find -lmingw32 collect2: ld returned 1 exit status I think it's time to cut the gordian knot here. Somehow your installation has got thoroughly busted; we could be here all week trying to find and fix it one problem at a time. Re-run setup.exe. Use the install from local package directory option. Click straight through to the chooser page. Set the following packages to 'reinstall': gcc, gcc-core, any other installed language packages gcc-mingw, gcc-mingw-core, any other installed gcc-mingw languages mingw-runtime w32api It would be helpful if you could run cygcheck -c a.txt before doing so, cygcheck -c b.txt afterwards, and then show us the output of grep 'gcc\|mingw\|w32api' a.txt b.txt. It would be good if we verify whether cygcheck spots these busted links and identifies them as a problem cheers, DaveK -- 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/
Re: activestate perl on cygwin
Kevin T Cella wrote: And what does #! look like? #! /usr/bin/perl Is there something that the space after the ! and before the / buys you? Readability. It is simply a question of style. I prefer the space. Has it come to that? Has it come to what? I simply asked a question. You provided an answer. Whose undies are in a bunch here? So your specifically saying by your shebang line - execute Cygwin's perl. As I state later, I use a symlink so I am infact executing Activestate perl. I guess it's style too but to me it just doesn't seem to make sense to point to one place then put a symlink in there to point to another place since you're hellbent on using ActiveState. Wouldn't it be much more stylistic and clear to simply point directly at the Perl you insist on using? Or did you really mean you are putting /usr/bin/perl in there to appear to be portable? That sort of answer I'd understand... except you have already stated that you don't care about portability. Seriously, are you trying to attack me or understand the problem? I am trying to be nice, I already apologized for my behavior earlier. My opinion on this situation does not require that I'm your friend. what does ls portion after #! in your script return? Before the conversion using cygpath, it returns the same as in the error: /home/kcella/bin/myscript.pl So then you are saying that you have no /usr/bin/perl? Is so then why do you put #! /usr/bin/perl in your script at all? I think I misunderstood the question. I had taken it to mean had I executed an ls on the incoming argument to my wrapper script (ie: the script filename), what would be the output. Now I see what you were trying to get at was if the interpreter referenced by the #! line exists on my system. As I state later, I use a symlink: $ ls -l /usr/bin/perl lrwxrwxrwx 1 kcella None 20 Jan 13 00:19 /usr/bin/perl - /c/Perl/bin/perl.exe Which is confusing. If you wish to use ActiveState then use ActiveState. If you wish to use Cygwin then use Cygwin. So now you are saying that you have no problem?!? Keep reading... The example I gave is for when I have no wrapper script and just create a symlink in /usr/bin/perl that points to /c/Perl/bin/perl.exe. Huh? There is no /c/... although I've heard of a way to do that I've also heard that it's not supported. Futher, why would you want to symlink /usr/bin/perl - /c/Perl/bin/perl.exe?!? Or, since you insist on using ActiveState, then why not specifically specify something like #!C:/Perl/bin/perl.exe or something like that? Again, it is just a question of style. And it's an answer of confusion. If I were to work on your script I would see /usr/bin/perl and think Great. He's using a standard perl and I should be able to easily use this under Linux or Cygwin's perl, etc. Wait... Err... No... He's symlinked this to ActiveState! and would be scratching my head wondering why you attempted to appear Unix-like with the shebang line yet are using a proprietary perl I have done it both ways, I prefer using linux style pahts. Which is why I still don't understand why you insist on ActiveState. Yes I know you said you want to use Win32 stuff but there's Win32 stuff that you could use in Cygwin too. If you really like Linux style paths, use Windows and Cygwin, seem to exert full control of the environment I would think using Cygwin's Perl, where you can more easily use Linux style paths not only for shebang but more conveniently throughout your script, would be something you'd want to do... BTW you never answered the question of what happens in ActiveState when you call setsid. I'll answer it for you. It returns Not implemented on this platform or something like that. IOW ActiveState does not implement nor support calling setsid. Why would you want setsid? It's useful in writing daemons, something I do on occasion. Along with that ActiveState doesn't seem to handle signals well. Forgive me here my memory is hazy as I had worked on this problem several years ago. I was attempting to write a daemon that would be essentially a Windows service and wanted it to be a multi threaded server meaning I wanted to fork and exec copies of myself to handle incoming requests. This requires proper signal handling. I was having problems with this so I queried in ActiveState forums and the guy responsible for signals in ActiveState responded that Windows doesn't support signals very well! Back to Cygwin's Perl I could call setsid as well as wrote a little test program that set, sent and trapped all 30 or so supported signals without a problem. So much for ActiveState! I mount c: to /c because it is much faster to type than /cygdrive/c/ and it makes more sense from a readability standpoint. I understand. Personally I use /dev because it's also short, is already there, seems to make sense to me that C is a device and allows me to have /dev/d, etc. However I realize it's non-standard and usually translate my usage
Re: 1.7.0 CVS mmap failure
On Sat, Jan 13, 2007 at 06:29:18AM -0800, Christopher Layne wrote: On Sat, Jan 13, 2007 at 11:25:08AM +0100, Corinna Vinschen wrote: On Jan 13 00:22, Christopher Layne wrote: The real question I have is why was what *should* have worked, not working? That has been answered immediately in the replies: http://cygwin.com/ml/cygwin/2007-01/msg00093.html http://cygwin.com/ml/cygwin/2007-01/msg00095.html http://cygwin.com/ml/cygwin/2007-01/msg00097.html Okay, I'll file this under looks like this is it, so it's probably it. A little less snark - a little more acceptance and understanding goes a long way. You could also file it under In a long running discussion, reading responses and asking for specific clarification is better than just asking general questions which seem to imply that you haven't been paying attention. YMMV. 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: gcc: installation problem, cannot exec 'cc1'
... Nop. [EMAIL PROTECTED] ~ $ grep 'gcc\|mingw\|w32api' a.txt b.txt a.txt:gcc 3.4.4-3OK a.txt:gcc-core 3.4.4-3OK a.txt:gcc-g++ 3.4.4-3OK a.txt:gcc-mingw20040810-1 OK a.txt:gcc-mingw-core 20050522-1 OK a.txt:gcc-mingw-g++20050522-1 OK a.txt:mingw-runtime3.11-1 OK a.txt:w32api 3.8-1 OK b.txt:gcc 3.4.4-3OK b.txt:gcc-core 3.4.4-3OK b.txt:gcc-g++ 3.4.4-3OK b.txt:gcc-mingw20040810-1 OK b.txt:gcc-mingw-core 20050522-1 OK b.txt:gcc-mingw-g++20050522-1 OK b.txt:mingw-runtime3.11-1 OK b.txt:w32api 3.8-1 OK I guess I am gonna have to reinstall the whole thing. ~ Thomas On 1/13/07, Dave Korn [EMAIL PROTECTED] wrote: On 13 January 2007 11:26, Thomas Antony wrote: Hello, The file crt2.o is present in /usr/lib/mingw. But the error remains the same. [EMAIL PROTECTED] ~ $ gcc -mno-cygwin hello.c /usr/bin/ld: crt2.o: No such file: No such file or directory collect2: ld returned 1 exit status I also found that I get another error if I compile the program from within the directory /usr/lib/mingw .See this: [EMAIL PROTECTED] /usr/lib/mingw $ gcc -mno-cygwin ~/hello.c /usr/bin/ld: cannot find -lmingw32 collect2: ld returned 1 exit status I think it's time to cut the gordian knot here. Somehow your installation has got thoroughly busted; we could be here all week trying to find and fix it one problem at a time. Re-run setup.exe. Use the install from local package directory option. Click straight through to the chooser page. Set the following packages to 'reinstall': gcc, gcc-core, any other installed language packages gcc-mingw, gcc-mingw-core, any other installed gcc-mingw languages mingw-runtime w32api It would be helpful if you could run cygcheck -c a.txt before doing so, cygcheck -c b.txt afterwards, and then show us the output of grep 'gcc\|mingw\|w32api' a.txt b.txt. It would be good if we verify whether cygcheck spots these busted links and identifies them as a problem cheers, DaveK -- 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/ -- 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: gcc: installation problem, cannot exec 'cc1'
Ugh, top-posting... Reformatted. On Sat, 13 Jan 2007, Thomas Antony wrote: On 1/13/07, Dave Korn [EMAIL PROTECTED] wrote: http://cygwin.com/acronyms/#PCYMTNQREAIYR. Thanks. [snip] It would be helpful if you could run cygcheck -c a.txt before doing so, cygcheck -c b.txt afterwards, and then show us the output of grep 'gcc\|mingw\|w32api' a.txt b.txt. It would be good if we verify whether cygcheck spots these busted links and identifies them as a problem ... Nop. [EMAIL PROTECTED] ~ $ grep 'gcc\|mingw\|w32api' a.txt b.txt a.txt:gcc 3.4.4-3OK a.txt:gcc-core 3.4.4-3OK a.txt:gcc-g++ 3.4.4-3OK a.txt:gcc-mingw20040810-1 OK a.txt:gcc-mingw-core 20050522-1 OK a.txt:gcc-mingw-g++20050522-1 OK a.txt:mingw-runtime3.11-1 OK a.txt:w32api 3.8-1 OK b.txt:gcc 3.4.4-3OK b.txt:gcc-core 3.4.4-3OK b.txt:gcc-g++ 3.4.4-3OK b.txt:gcc-mingw20040810-1 OK b.txt:gcc-mingw-core 20050522-1 OK b.txt:gcc-mingw-g++20050522-1 OK b.txt:mingw-runtime3.11-1 OK b.txt:w32api 3.8-1 OK I guess I am gonna have to reinstall the whole thing. Since cygcheck uses the listings of the installed files from the package distribution tarball, it's not going to catch missing files/symlinks that are supposed to be created during the postinstall phase. In fact, since gcc-mingw is distributed as a tarball that is extracted in a postinstall script, it's not possible to check whether it's incomplete using cygcheck. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Freedom is just another word for nothing left to lose... -- Janis Joplin -- 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: Snapshot speed on managing files
On Jan 12 10:34, Brian Ford wrote: On Fri, 12 Jan 2007, Corinna Vinschen wrote: Current CVS contains a change which is probably the cause for that. Before deleting a file, the file is moved to the recycle bin. Couldn't we make this conditional only if a regular delete fails because the file is in use? Would it then only penalize deletes of open files? (Incidentally, I've noticed this as well.) I have to pick up the thread at this point again because... ... because I was just implementing what Dave was asking for. What I'm trying to do now is to open the file with the sharing flags set to all-zero. If I get a sharing violation I know the file is in use and should be moved to the bin. If opening the file worked I can just close the handle again and the file will be deleted immediately (delete-on-close semantics). Ok, obviously I needed a testcase to see the speed improvement of this method. So I came up with this one: $ cat deltest.sh EOF #!/bin/sh echo -n Creating files... for d in `seq -w 1 32` do mkdir dir$d for f in `seq -w 1 32` do dd if=/dev/zero of=dir$d/file$f bs=64K count=16 /dev/null 21 done done echo Ok. echo -n Deleting files ... time rm -rf dir* EOF $ chmod +x ./deltest.sh Ok, next thing is taking the time with the current implementation which always moves the file to the bin: $ ./deltest.sh Creating files... Ok. Deleting files ... real0m2.546s user0m0.233s sys 0m0.578s Huh? 2.5s for what Marco tells us needs 1m40 on his machine? Anyway, let's try with the new implementation: $ ./deltest.sh Creating files... Ok. Deleting files ... real0m2.359s user0m0.187s sys 0m0.531s Can anybody explain to me why moving to the bin should take that long on another machine? Apparently the performance hit is barely visible on my machine. It's hardly worth to change the code. Maybe I'm just suffering from caching effects? I added a really long `find' run between creating and deleting the files, but that made the results in both variations even better! 1.4s vs. 1.2s. So, what's up on the slow machines? Virus checker? But why should an open/close sequence not be hit by a virus checker, while an open/move/ close sequence gets hit that badly? I don't quite get it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Snapshot speed on managing files
On Sat, 13 Jan 2007, Corinna Vinschen wrote: On Jan 12 10:34, Brian Ford wrote: On Fri, 12 Jan 2007, Corinna Vinschen wrote: Current CVS contains a change which is probably the cause for that. Before deleting a file, the file is moved to the recycle bin. Couldn't we make this conditional only if a regular delete fails because the file is in use? Would it then only penalize deletes of open files? (Incidentally, I've noticed this as well.) I have to pick up the thread at this point again because... ... because I was just implementing what Dave was asking for. What I'm trying to do now is to open the file with the sharing flags set to all-zero. If I get a sharing violation I know the file is in use and should be moved to the bin. If opening the file worked I can just close the handle again and the file will be deleted immediately (delete-on-close semantics). Ok, obviously I needed a testcase to see the speed improvement of this method. So I came up with this one: $ cat deltest.sh EOF #!/bin/sh echo -n Creating files... for d in `seq -w 1 32` do mkdir dir$d for f in `seq -w 1 32` do dd if=/dev/zero of=dir$d/file$f bs=64K count=16 /dev/null 21 done done echo Ok. echo -n Deleting files ... time rm -rf dir* EOF $ chmod +x ./deltest.sh Ok, next thing is taking the time with the current implementation which always moves the file to the bin: $ ./deltest.sh Creating files... Ok. Deleting files ... real0m2.546s user0m0.233s sys 0m0.578s Huh? 2.5s for what Marco tells us needs 1m40 on his machine? Anyway, let's try with the new implementation: $ ./deltest.sh Creating files... Ok. Deleting files ... real0m2.359s user0m0.187s sys 0m0.531s Can anybody explain to me why moving to the bin should take that long on another machine? Apparently the performance hit is barely visible on my machine. It's hardly worth to change the code. Maybe I'm just suffering from caching effects? I added a really long `find' run between creating and deleting the files, but that made the results in both variations even better! 1.4s vs. 1.2s. So, what's up on the slow machines? Virus checker? But why should an open/close sequence not be hit by a virus checker, while an open/move/ close sequence gets hit that badly? I don't quite get it. Does http://cygwin.com/ml/cygwin/2007-01/msg00383.html seem like a plausible answer? I'm just reiterating it because it may have been lost among other suggestions in this thread. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Freedom is just another word for nothing left to lose... -- Janis Joplin -- 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: Snapshot speed on managing files
On Jan 13 14:08, Igor Peshansky wrote: On Sat, 13 Jan 2007, Corinna Vinschen wrote: [... needless full quote deleted ...] Can anybody explain to me why moving to the bin should take that long on another machine? Apparently the performance hit is barely visible on my machine. It's hardly worth to change the code. Maybe I'm just suffering from caching effects? I added a really long `find' run between creating and deleting the files, but that made the results in both variations even better! 1.4s vs. 1.2s. So, what's up on the slow machines? Virus checker? But why should an open/close sequence not be hit by a virus checker, while an open/move/ close sequence gets hit that badly? I don't quite get it. Does http://cygwin.com/ml/cygwin/2007-01/msg00383.html seem like a plausible answer? I'm just reiterating it because it may have been lost among other suggestions in this thread. What about http://cygwin.com/ml/cygwin/2007-01/msg00384.html? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Snapshot speed on managing files
On Sat, 13 Jan 2007, Corinna Vinschen wrote: On Jan 13 14:08, Igor Peshansky wrote: On Sat, 13 Jan 2007, Corinna Vinschen wrote: [... needless full quote deleted ...] Can anybody explain to me why moving to the bin should take that long on another machine? Apparently the performance hit is barely visible on my machine. It's hardly worth to change the code. Maybe I'm just suffering from caching effects? I added a really long `find' run between creating and deleting the files, but that made the results in both variations even better! 1.4s vs. 1.2s. So, what's up on the slow machines? Virus checker? But why should an open/close sequence not be hit by a virus checker, while an open/move/ close sequence gets hit that badly? I don't quite get it. Does http://cygwin.com/ml/cygwin/2007-01/msg00383.html seem like a plausible answer? I'm just reiterating it because it may have been lost among other suggestions in this thread. What about http://cygwin.com/ml/cygwin/2007-01/msg00384.html? D'oh. Sorry for the noise. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Freedom is just another word for nothing left to lose... -- Janis Joplin -- 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: activestate perl on cygwin
I simply asked a question. You provided an answer. Whose undies are in a bunch here? As did I. Sorry I misinterpreted your tone. Wouldn't it be much more stylistic and clear to simply point directly at the Perl you insist on using? Or did you really mean you are putting /usr/bin/perl in there to appear to be portable? That sort of answer I'd understand... except you have already stated that you don't care about portability. It is my opinion that it looks better. I'm sorry you disagree. Seriously, are you trying to attack me or understand the problem? I am trying to be nice, I already apologized for my behavior earlier. My opinion on this situation does not require that I'm your friend. I am not asking for friendship, just civility. And it's an answer of confusion. If I were to work on your script I would see /usr/bin/perl and think Great. He's using a standard perl and I should be able to easily use this under Linux or Cygwin's perl, etc. Wait... Err... No... He's symlinked this to ActiveState! and would be scratching my head wondering why you attempted to appear Unix-like with the shebang line yet are using a proprietary perl My scripts will not leave this computer. I have absolutely no intention of sharing any of my code. The only person who has to understand it is me. I'm sorry it confused you. I know you said you want to use Win32 stuff but there's Win32 stuff that you could use in Cygwin too. If you really like Linux style paths, use Windows and Cygwin, seem to exert full control of the environment I would think using Cygwin's Perl, where you can more easily use Linux style paths not only for shebang but more conveniently throughout your script, would be something you'd want to do... Agreed. In the long term it may happen, but not at this moment. BTW you never answered the question of what happens in ActiveState when you call setsid. I'll answer it for you. It returns Not implemented on this platform or something like that. IOW ActiveState does not implement nor support calling setsid. Why would you want setsid? It's useful in writing daemons, something I do on occasion. Along with that ActiveState doesn't seem to handle signals well. Forgive me here my memory is hazy as I had worked on this problem several years ago. I was attempting to write a daemon that would be essentially a Windows service and wanted it to be a multi threaded server meaning I wanted to fork and exec copies of myself to handle incoming requests. This requires proper signal handling. I was having problems with this so I queried in ActiveState forums and the guy responsible for signals in ActiveState responded that Windows doesn't support signals very well! Back to Cygwin's Perl I could call setsid as well as wrote a little test program that set, sent and trapped all 30 or so supported signals without a problem. So much for ActiveState! I will deal with it if an when I need to write a daemon script. Thanks for the information. You've come in here and asked a question to which you have been given an answer. You insist on mixing together to separate distinct technologies that were not designed to work together where experienced people here advise that you stop fighting the two use the technologies more in the way they were intended than in ways they weren't intended. Ah but you insist on doing it the hard way. Fine then, have fun with your problem is not an unreasonable nor should it be an unexpected response for you. I have already solved my problem, I will be using Mr. Peshansky's idea. You have been asking me questions ever since, I am simply trying to provide you with answers thereby extending to you the same courtesy others have on this thread. -- 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: Snapshot speed on managing files
On 13 January 2007 18:19, Corinna Vinschen wrote: Ok, next thing is taking the time with the current implementation which always moves the file to the bin: $ ./deltest.sh Creating files... Ok. Deleting files ... real0m2.546s user0m0.233s sys 0m0.578s Huh? 2.5s for what Marco tells us needs 1m40 on his machine? Anyway, let's try with the new implementation: $ ./deltest.sh Creating files... Ok. Deleting files ... real0m2.359s user0m0.187s sys 0m0.531s Can anybody explain to me why moving to the bin should take that long on another machine? Apparently the performance hit is barely visible on my machine. It's hardly worth to change the code. So, what's up on the slow machines? How full are your respective recycle bins? I've noticed just through deleting things in ordinary windows explorer that the recycle bin thrashes like crazy when it starts to get full; seriously thrashes, like 15 or 20 seconds just to delete a small file. cheers, DaveK -- 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/
bash in process regular expressions
Hi, when I write a bash script using regular
expressions something goes wrong with the single
quotes that I do understand should surround the
regular expression. The code I show below works okay
when the single quotes are removed, but it does not as
shown. For this example the single quotes are not
really needed but is useful for showing my problem, my
real script does need the single quotes because I'm
trying to match several sub-expressions.
any help is appreciated,
thanks,
Rodrigo
#!/bin/bash
if [[ hola =~ '(.*)' ]]
then
echo ${BASH_REMATCH[1]}
else
echo arghhh
fi
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/
--
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: bash in process regular expressions
Rodrigo Amestica wrote: Hi, when I write a bash script using regular expressions something goes wrong with the single quotes that I do understand should surround the regular expression. The code I show below works okay when the single quotes are removed, but it does not as shown. For this example the single quotes are not really needed but is useful for showing my problem, my real script does need the single quotes because I'm trying to match several sub-expressions. Read the replies in this recent thread: http://www.cygwin.com/ml/cygwin/2007-01/msg00339.html Brian -- 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: bash in process regular expressions
On 13 January 2007 23:38, Brian Dessent wrote: Rodrigo Amestica wrote: Hi, when I write a bash script using regular expressions something goes wrong with the single quotes that I do understand should surround the regular expression. The code I show below works okay when the single quotes are removed, but it does not as shown. For this example the single quotes are not really needed but is useful for showing my problem, my real script does need the single quotes because I'm trying to match several sub-expressions. Read the replies in this recent thread: http://www.cygwin.com/ml/cygwin/2007-01/msg00339.html Brian But see also http://lists.gnu.org/archive/html/bug-bash/2006-10/msg00064.html http://lists.gnu.org/archive/html/bug-bash/2006-10/msg00065.html cheers, DaveK -- 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/
Been hunting all over Google and Cygwin for an hour, still can't find an answer
Does Cygwin support large files over 4GB on Windows XP yet? I'd really like to get rsync to work with large files on Cygwin on Windows XP if at all possible. Do you know anybody who has done that? I've tried it with rdiff-backup using a patched librsync from Fedora Core 5, but I had other problems with rdiff, so now I'd like to see if rsync will do it. -- 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: Been hunting all over Google and Cygwin for an hour, still can't find an answer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Richard Steven Hack on 1/13/2007 7:32 PM: Does Cygwin support large files over 4GB on Windows XP yet? Why don't you try it and see? The answer is, yes. - -- 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 iD8DBQFFqZxf84KuGfSFAYARAqh5AKC9bygbxUyHRfUwKHz7prQ3Hf5hNQCgodl8 Ne/OeoGHxbrlgqGnCkYy5bY= =Bsbr -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/
bash:fork: Resource temporarily unavailable
I have installed cygwin with setup version 2.510.2.2, and also put the path to C:\cygwin\bin. I start cygwin - all is okay, command pwd is okay, when I start command ls I got the following error: 5 [main] bash 3268 child_copy: stack write copy failed, 0x22C3B0..0x23, done 1624, windows pid 2278084, Win32 error 998 5651 [main] bash 3268 fork: child 3400 - pid 3400, exitval 0x103, errno 11 bash: fork: Resource temporarily unavailable How can I solve it ? Regards Manfred -- 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/
