This is the mail archive of the
mailing list for the Cygwin project.
Re: Many Cygwin (mintty) windows - How to close all?
Dave Korn <firstname.lastname@example.org> writes:
> Haojun Bao wrote:
>> The C# .net programming ...
> Yeh. Or you could just use the cygwin native tools from the procps package,
> which have the advantage of not having to install hundreds of megabytes of MS
You don't need to install the Visual Stuio, the compiled binary is
also in the svn, so you only need the vs-redist, which probably is
>> The C# .net programming provides a `System.Diagnostics' package, which
>> you can use to enum every process and every PE32 executable (dll or exe)
>> loaded by each process, then you just grep "cygwin1.dll" and
>> TerminateProcess each of them. Put it in a python script...
> How on earth is that not *hugely* more trouble and effort than just typing
> "kill -9 -1"?
>> Another thing, when running `terminateModule.py', the python must be the
>> native win32 python, with pywin32 installed, not the one shipped with
>> cygwin. The reason should be apparent. Then there comes another problem,
> First you have a problem. Then you decided to use a non-cygwin version of
> something that is also a cygwin app to help you. Now you have two problems!
> This entire design is pointlessly baroque.
Not so bad if I get the idea reused:-) See below.
>> the pywinstart.exe is a *general* .exe file, which will only invoke bash
>> with a `helper.sh' and the command line arguments, in helper.sh, it will
>> see pywinstart.exe is executing, so instead it will invoke a
>> *pywinstart.sh*, which then *cygstart* the native python, with the .py
>> file path "~/bin/windows/terminateModule.py" transformed to it's win32
>> path using `cygpath -alm'
> Are you being deliberately masochistic? Why not do it all blindfold as well
> just to make things even harder on yourself? Installing the .NET runtime, and
> a whole new python distro, and a bunch of scripts, and all this just to
> duplicate the existing functionality that "pkill" and "pgrep" provide
> in a
I didn't know `pkill' and `pgrep' before, so I gave it a try right
now. To my suprise, it can grep and kill non-cygwin programs such as notepad.exe.
But only if it is started under cygwin, not if it's from the Run-Dialog.
> fraction of the size and hassle? *shrugs* It's your life to waste, I
>> Be fore-warned: it will change your keyboard's CapsLock into Control,
>> among other not very polite things:-)
> So apart from being far more trouble, taking far more time and effort, and
> disk space, and cpu cycles, and being fragile, it ALSO has the additionl
> benefit of messing up your settings?
> Cost-benefit trade-off. You are doing it wrong.
Thanks for pointing this out to me. I'm really sweating and thinking
now. But then I must go on to explain why I have done those things. It
all because I need to make cygwin/non-cygwin programs work together. For
e.g., I use Visual Studio, and there's a visemacs addin which can send
files to emacs for editting. It works for the native Emacs, but later I
switched to cygwin-Emacs, and visemacs stopped working, because it will
send the file path in win32 format. So using the same idea (and the same
binary, only another hardlink), I have an emacsedit.exe and
emacsedit.sh, in the latter `cygpath -au' will be used to invoke
emacsclient.exe with the posix pathname.
Also, I use firefox chm reader addon to read some e-book, I want to be
able to double click on a .chm file and it get opened with firefox, not
hh.exe. I need write a `ffchm.sh' like this:
firefox chm:file://"`cygpath -alw \"$1\"`"
But then, I can't associate .chm with this .sh file in registry, it must
be a .exe file, so another hardlink as ffchm.exe to my over-used
> 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
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple