From: cgf AT bbc DOT com (Christopher Faylor) Subject: Re: Cygnus b19 gcc and Mingw32 10 Mar 1998 20:26:57 -0800 Message-ID: <199803101751.MAA01638.cygnus.gnu-win32@hardy.bbc.com> To: earnie_boyd AT hotmail DOT com Cc: gnu-win32 AT cygnus DOT com >>>Well the fix is to undo the changes and go back to the way it was >>>handled. My example worked in b18, it should work now. One of the >>>beauties about this was that I was able to live in both worlds. Now, I >>>have to exit bash to execute a native program. >> >>What are you talking about? What changes are you referring to? >> >>If you don't use CYGWIN32=tty then MORE should work correctly with my >>.dll. Are you saying that MORE doesn't work when CYGWIN32=notty? > >OK. Setting CYGWIN32=notty before starting bash will cause "ls | >more.com" to work. Setting CYGWIN32=notty or vice versa after bash >starts makes no difference. It was reported that the CYGWIN32 >environment variable should be an interactive one. CYGWIN32 is interactive. The tty setting is "sticky", however. The reason for this is that if your stdin is a tty and you set CYGWIN32=notty, then any program which attempts to read from stdin will not know how to "connect" to the tty that is associated with stdin. That actually could result in "core dumps" in the child program. Essentially, once you have started a "tty" on your console it will always be a tty. Possibly there are other ways to do this, but currently that's how it works in cygwin. You can blame me for this behavior. >WinNT 3.51 is what I'm using, here. I do have W95 at home. Oh. That's what I'm using. I didn't even know I had more on my machine. Now I've tried it and I see what you're reporting. I'll have to think about this to see if there some solution to this problem. -- Http://www.bbc.com/ cgf AT bbc DOT com "Strange how unreal VMS=>UNIX Solutions Boston Business Computing the real can be." - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".