zsh-workers
 help / color / mirror / code / Atom feed
* Re: Bug in cygwin with select and master pty
@ 2000-11-12 20:19 cgf
  2000-11-13 11:12 ` Andrej Borsenkow
  0 siblings, 1 reply; 5+ messages in thread
From: cgf @ 2000-11-12 20:19 UTC (permalink / raw)
  To: zsh-workers

In article <001e01c049b7$7f159ea0$21c9ca95@mow.siemens.ru>,
Andrej Borsenkow <Andrej.Borsenkow@mow.siemens.ru> wrote:
>> } About select - so far there seems to be no known problems under cygwin
>> } (that does not mean, there are no problems).
>>
>>OK, if there are no known problems with select, then the test on line
>>1376 can change from `ret <= 0' to `ret < 0' -- and in that case it's
>>possible that we could split read_poll() into two cases, HAVE_SELECT v.
>>all the other code that's there.  I won't do that for now, though.
>
>Life is fun.  5 minutes later I discovered a bug that made blocking
>multiline reads (with or without pattern) hang at the end of the first
>line.  I sent sort of a patch to cygwin list, but I am not sure if it
>really does the right thing (it fixed the bug I've seen, O.K.  The
>question is whether it introduced another bugs :-)

I didn't see any followup to this but the new (1.1.5) release of cygwin
should not have this problem.

>Anyway, fiddling with currently released versions of cygwin is pretty
>useless wrt to zpty (all of them are buggy in some way).  Unfortunately
>(to us) zsh seems to be the only program that has these problems.  With
>all implications.

Have all of these problems been reported to the cygwin mailing list?  Are
there still problems in 1.1.5?

>The pgrp problem still remains.

What is the pgrp problem?  Was this reported to the cygwin mailing list?

cgf


^ permalink raw reply	[flat|nested] 5+ messages in thread
* PATCH: read_poll Re: PATCH: Zpty cleanup (merge 13061 with 13116)
@ 2000-11-08 15:58 Bart Schaefer
  2000-11-08 19:10 ` Bug in cygwin with select and master pty Andrej Borsenkow
  0 siblings, 1 reply; 5+ messages in thread
From: Bart Schaefer @ 2000-11-08 15:58 UTC (permalink / raw)
  To: zsh-workers

On Nov 8, 11:20am, Sven Wischnowsky wrote:
}
} Bart Schaefer wrote:
} 
} > However, that does not mean that the rest of the tests should be skipped
} > when select() returns 0.  A return of 0 means the select() timed out,
} > which (apparently) might happen under Cygwin even if there actually are
} > characters available to be read.  Peter/Andrej, is that the case?
} 
} I don't know about Cygwin, but that blocking read (line 1381) is
} exactly the test I wanted to avoid.

The read on line 1381 is *non-*blocking.  Since polltty is now always zero
when called from zpty, the setblock_fd() call is made before the read() is
attempted.  That was the patch I first committed which started me down the
road of merging in your changes.

On Nov 8,  1:42pm, Andrej Borsenkow wrote:
} Subject: RE: PATCH: Zpty cleanup (merge 13061 with 13116)
}
} I had not much time recently. Casual test shows, that zpty is currently
} completely broken on current Cygwin (1.1.5-4 as of this writing); I do not
} claim that it is zsh problem, but recent changes may have made it worse.

More on this in the other zpty thread ...

} About select - so far there seems to be no known problems under cygwin
} (that does not mean, there are no problems).

OK, if there are no known problems with select, then the test on line
1376 can change from `ret <= 0' to `ret < 0' -- and in that case it's
possible that we could split read_poll() into two cases, HAVE_SELECT v.
all the other code that's there.  I won't do that for now, though.

This still doesn't address my complaint that select() on my linux box
returns "ready for reading" when in fact the result of read() will be
an I/O error.  That makes no difference to `read -t' (for which the
read_poll() code was originally written) but it screws up the return
value of `zpty -r'.

On Nov 8,  5:03pm, Andrej Borsenkow wrote:
} Subject: read_poll RE: PATCH: Zpty cleanup (merge 13061 with 13116)
}
} read_poll tries to read from fd and stores the character it has read in
} readchar; that is cmd->read when called from checkptycmd. But this value does
} not seem to be used anywhere in read loop that looks like read_poll simply
} eats up this readahead char ...

You're correct.  The code Sven referenced at line 474 needs to be repeated
after line 484.

Index: Src/utils.c
===================================================================
@@ -1373,7 +1373,7 @@
 #endif
 #endif
 
-    if (ret <= 0) {
+    if (ret < 0) {
 	/*
 	 * Final attempt: set non-blocking read and try to read a character.
 	 * Praise Bill, this works under Cygwin (nothing else seems to).
Index: Src/Modules/zpty.c
===================================================================
@@ -482,6 +482,11 @@
 	    checkptycmd(cmd);
 	    if (cmd->fin)
 		break;
+	    if (cmd->read != -1) {
+		buf[++used] = (char) cmd->read;
+		seen = 1;
+		cmd->read = -1;
+	    }
 	}
 	if ((ret = read(cmd->fd, buf + used, 1)) == 1) {
 	    seen = 1;


-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   


^ permalink raw reply	[flat|nested] 5+ messages in thread
end of thread, other threads:[~2000-11-13 16:59 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-11-12 20:19 Bug in cygwin with select and master pty cgf
2000-11-13 11:12 ` Andrej Borsenkow
2000-11-13 16:21   ` Chris Faylor
2000-11-13 16:59     ` Andrej Borsenkow
  -- strict thread matches above, loose matches on Subject: below --
2000-11-08 15:58 PATCH: read_poll Re: PATCH: Zpty cleanup (merge 13061 with 13116) Bart Schaefer
2000-11-08 19:10 ` Bug in cygwin with select and master pty Andrej Borsenkow

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).