Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com Message-Id: <3765CCB0.4248710E@kiwi.iamp.tohoku.ac.jp> Date: Tue, 15 Jun 1999 04:46:56 +0000 From: Samy Alex ZAIMI Reply-To: zaimi AT kiwi DOT iamp DOT tohoku DOT ac DOT jp Organization: Institute for Advanced Materials Processing - Tohoku University X-Mailer: Mozilla 4.5 [fr] (Win95; I) X-Accept-Language: fr,en,ja Mime-Version: 1.0 To: cygwin Subject: cygwin1.dll & tty (was Re: Ctrl-c in bash ...) References: <3 DOT 0 DOT 5 DOT 32 DOT 19990614133654 DOT 00b2dd50 AT nats13 DOT informatik DOT uni-hamburg DOT de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id WAA15605 Dan Herron a écrit : > At 01:32 AM 5/21/99 -0400, Kevin Low wrote: > > I am using bash from cygwin b20. How do I prevent all background > > jobs from exiting whenever I press ctrl-c in bash? For example, if > > I run telnet in the background, pressing ctrl-c will kill telnet. > > You need to set "tty" in your CYGWIN environment variable. E.g., > > export CYGWIN="tty" (or set it in the "system"--> environment control-panel.) > > Somebody told me this a while ago, but pointed out that this screws up > lots of programs that use the console IO. And, indeed, it made all sorts > of things go wrong for me, although I can't actually recall *what* at > this point. Well, that's very simple : shell scripts like ./configure can fail with here documents if tty is used instead of notty. Afterwards, bash behaves strangely : no more history, no more tab completion, commands echoed twice ... There is a good description of the symptoms (but not of the remedy) in a previous post by Mikey : 1999/02/12/18:43:39 (Here documents in ash shell scripts mess up stdin on 9x). Glenn Spell said that this problem is solved using 19990502's snapshot. I have tried another snapshot, from 19990603, said to be stable as well, and I have tried the tests proposed by Mikey with here documents. The problem is solved as well. One remark though : I had an old cygwin1.dll under windows directory (needed to call programs build with cygwin from outside the bash shell). It is necessary to rename it, or erase it with the new dll. This is a bit strange to me : I have decided not to mix Win and CygWin with the following two settings : 1. the $PATH variable inside the bash shell doesn't include C:\WINDOWS 2. the %PATH% variable inside a DOS shell (set inside my AUTOEXEC) doesn't include CygWin paths. I thought this would be enough to separate the two worlds. Still, if I do cygcheck gcc I have : D:\usr\bin\gcc.exe C:\WINDOWS\SYSTEM\advapi32.dll C:\WINDOWS\SYSTEM\KERNEL32.dll D:\usr\bin\cygwin1.dll <-------------- The new one. C:\WINDOWS\SYSTEM\user32.dll C:\WINDOWS\SYSTEM\GDI32.dll but if the old "c:\windows\cygwin1.dll" is present, gcc doesn't work. If it is missing or replaced by the new dll, gcc does work. How come that "c:\windows\cygwin1.dll" has an influence on gcc and at the same time seems not to be needed ? -- SAZ -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com