* 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
* RE: Bug in cygwin with select and master pty
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
0 siblings, 1 reply; 5+ messages in thread
From: Andrej Borsenkow @ 2000-11-13 11:12 UTC (permalink / raw)
To: cgf, zsh-workers
> -----Original Message-----
> From: cgf@redhat.com [mailto:cgf@redhat.com]
> Sent: Sunday, November 12, 2000 11:20 PM
> To: zsh-workers@sunsite.auc.dk
> Subject: Re: Bug in cygwin with select and master pty
>
>
> 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.
>
Chris, are you hearing on this list too?
> >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?
>
Yes. Build problem with termcap, EOF problem with pty, one more problem in
pre-1.1.5 snapshots and the above select problem.
The select problem is not fixed in 1.1.5-6.
> >The pgrp problem still remains.
>
> What is the pgrp problem? Was this reported to the cygwin mailing list?
>
Some zpty code was changed and now zsh cannot attach to allocated pty (with
error message cannot set pgrp). No, this was not reported to cygwin list
because
- the problem resulted from zsh code change, so I first had to make sure it
was cygwin problem
- I have had enough "this is open source" replies. I'm sorry to say, but
reporting anything to cygwin list is pretty useless unless one can either
provide a patch or two-line program to reproduce the problem. I currently
cannot do either.
If you do not mind to update zsh CVS, you can see the last problem. Just do
something like
zmodload zsh/zpty
zpty sh /bin/sh
and now we have:
mw1g017@MW1G17C% zmodload zsh/zpty
mw1g017@MW1G17C% zpty sh /bin/sh
mw1g017@MW1G17C% ps -l
PID PPID PGID WINPID TTY UID STIME COMMAND
1592 1 1592 1592 0 1006 14:05:53 /usr/bin/zsh
1596 1592 1596 1596 -1 1006 14:06:14 /usr/bin/zsh
1620 1592 1620 1624 0 1006 14:06:33 /usr/bin/ps
where provess 1596 is a child that tried to attach to allocated pty. If you
read the output you get:
mw1g017@MW1G17C% zpty -r sh foo \*$'\n'
mw1g017@MW1G17C% print -r $foo
zsh: can't set tty pgrp: not owner
This did work before last change; the main change was that zsh now opens both
master and slave fd's of pty with O_NOCTTY. This works on Unix.
-andrej
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug in cygwin with select and master pty
2000-11-13 11:12 ` Andrej Borsenkow
@ 2000-11-13 16:21 ` Chris Faylor
2000-11-13 16:59 ` Andrej Borsenkow
0 siblings, 1 reply; 5+ messages in thread
From: Chris Faylor @ 2000-11-13 16:21 UTC (permalink / raw)
To: zsh-workers
On Mon, Nov 13, 2000 at 02:12:50PM +0300, Andrej Borsenkow wrote:
>> I didn't see any followup to this but the new (1.1.5) release of cygwin
>> should not have this problem.
>
>Chris, are you hearing on this list too?
I've been reading the zsh-workers list for about four or five years, yes.
>> >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?
>
>Yes. Build problem with termcap, EOF problem with pty, one more problem in
>pre-1.1.5 snapshots and the above select problem.
None of these statements are adequate to track any problems down, unfortunately.
>The select problem is not fixed in 1.1.5-6.
1.1.5-6 is history.
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
* Bug in cygwin with select and master pty
2000-11-08 15:58 PATCH: read_poll Re: PATCH: Zpty cleanup (merge 13061 with 13116) Bart Schaefer
@ 2000-11-08 19:10 ` Andrej Borsenkow
0 siblings, 0 replies; 5+ messages in thread
From: Andrej Borsenkow @ 2000-11-08 19:10 UTC (permalink / raw)
To: zsh-workers
>
> } 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 :-)
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.
The pgrp problem still remains.
-andrej
^ 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).