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 <zaimi AT kiwi DOT iamp DOT tohoku DOT ac DOT jp>
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 <cygwin AT sourceware DOT cygnus DOT com>
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>
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

- Raw text -