Mail Archives: cygwin/1998/03/10/20:26:57
>>>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".
- Raw text -