On 3/2/06, Christopher Faylor <me@xxxxxx> wrote: > >That's not enough. > >Try interrupting busy processes. Like "git pull", "git clone" or make. > > Are you saying that typing CTRL-C doesn't work when you use "git pull"? It does. Almost always. It's the seldom cases when this does not really work which annoy me that much. > If so, give me a real bug report that I can look into. I interrupt > "busy" processes on cygwin all of the time so I'm not going to spend a > few hours typing "git pull" on my system only to find out that you are > talking about an environment that uses ActiveState perl on Windows 95 > using Netware. well, it is almost exactly the case: WinNT 2K. And I cannot change this. > If you are reporting a problem you need to provide details. I am NOT reporting a problem. Everyone knows there are these problems, it's just almost no one (including me) cares enough about getting anything to work sanely on windows. Please, stop assuming that every my complaint is a bug report about cygwin. It is not. You can use my mails as you please, even as bug reports. If you ask nicely, I can provide more details maybe. But I am not asking YOU for anything, and not complaining to YOU about anything. I _do_not_ like how Cygwin workarounds windows, but I respect the effort and understand why it happens. Still, I'd prefer it die. I'll try to keep it moving, but no farther than needed and only when I really have to. > There are also other mechanisms for a native windows > program to deal with CTRL-C so this really shouldn't be an issue for > any well-written program. In windows you have to do hell of a lot useless typing to write what you consider a "well-written program". > >I wont be pressing anyone to implement them in windows, having the > >knowledge. What I'd actually suggest is to drop their implementation > >entierly, returning ENOSYS, > > You're not being clear again, but if you are actually promoting the > notion of cygwin not implementing signals then that is a really daft > idea. Really. Go to the Cygwin web site and look at all of the > packages which have been ported. Now think about how they would work if > Cygwin didn't support signals. bash wouldn't work, openssh, X wouldn't > work. That's right. They are not _ported_. I'm not interested in xterm which prints page in a minute. > >so that programs are not fooled into believing that the system will > >work as expected. It never will. "Ctrl-C" in windows console is just > >a shortcut to TerminateProcess, live with that. > > Let me say it again since it isn't clear that you are getting it. If > signals in a pure cygwin environment don't work then that is *a bug*. Whatever you say. I never expected them to, personally. > If you are running pure windows programs in the mix with cygwin programs > then if *they* don't stop when you hit CTRL-C, that is undoubtedly a bug > in that pure windows program. Maybe. I wouldn't blame that poor windows programmer though: it's hard, boring and in 99.9999% of starts of that program - dead code. > If you find that a pure windows program terminates when run from a > windows command prompt but keeps running when run by a cygwin program > then that is likely a cygwin problem that can be reported to the cygwin > mailing list. gui applications detach from cmd (not from cygwin console), so that kind of pointless exercise. > I'd suggest that using git with native windows programs should probably > be considered "unsupported" since you seem to be having so much trouble > with it. I'd suggest calling cygwin ports unsupported. > >I cannot use umask, because I have to use stupid windows programs, and > >they always create "executable" *.c and *.h, and I cannot blindly > >remove it with something like "chmod -R -x", because it'd remove it > >also from executables. > > find . -name '*.[ch]' | xargs chmod a-x find . -name '*.[ch]' -o -name '*.[ch]pp' -o -name Makefile -o -name '*.txt' -o ...ooh! damn it^C -print0| xargs -0 chmod -x You oversimplifying. - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html