accessing zpty after child has finished (Mac OS X)

accessing zpty after child has finished (Mac OS X)

[Jun T.]

On Mac OS X, 'make check' succeeds normally, but zpty still has
some problems:

mac$ zpty x date
(date finishes immediately)
mac$ zpty -r x      # (1): no output
mac$ zpty
(20359) x: date     # should be (finished)
mac$ zpty -w x foo
(2): zsh goes into an infinite loop (100% cpu usage).

Suppose the child on the slave side of the pty has already finished,
and we try to read from the master by 'ret = read(master, buf, 1)'.
On Linux, what we get is either
  the data written to the slave but not yet read from the master,
  or ret = -1 (with errno set to EIO) if no such data remains.

On Mac OS X, the data not yet read by the master is lost,
and read() always returns 0 (not -1). 

The infinite loop (2) is in ptywritestr(); the for loop starting at
line 676 of zpty.c never breaks and loops forever, because checkptycmd()
(called at line 689) doesn't set cmd->fin. The following patch solves
this problem, and I hope it does no harm on other OS.

I feel the data loss (1) is OK at least for now.
The only way I can think of to avoid the data loss is to open the
slave in the parent and keep the file descriptor open in the parent.
But I believe it causes trouble on other OS.


diff --git a/Src/Modules/zpty.c b/Src/Modules/zpty.c
index fca0cc1..b0c339b 100644
--- a/Src/Modules/zpty.c
+++ b/Src/Modules/zpty.c
@@ -510,7 +510,7 @@ checkptycmd(Ptycmd cmd)
 
     if (cmd->read != -1 || cmd->fin)
 	return;
-    if ((r = read(cmd->fd, &c, 1)) < 0) {
+    if ((r = read(cmd->fd, &c, 1)) <= 0) {
 	if (kill(cmd->pid, 0) < 0) {
 	    cmd->fin = 1;
 	    zclose(cmd->fd);
 

Re: accessing zpty after child has finished (Mac OS X)

[Bart Schaefer]

On Dec 17,  1:33am, Jun T. wrote:
}
} -    if ((r = read(cmd->fd, &c, 1)) < 0) {
} +    if ((r = read(cmd->fd, &c, 1)) <= 0) {

I don't see any significant ill effect from this other than some extra
kill(pid, 0) calls which should be low overhead.

There is a chance that it will leave some child output un-consumed on
platforms where the PTY does maintain the buffer until both ends are
closed.  There's no generalized way around this except for using the
same kind of special sync write/read that's exchanged when the PTY is
being set up, but that would have to be done out of band, whereas the
startup sync is in-band (uses the PTY itself).

However, Jun's change makes a subsequent test unnecessary.  I propose
this instead:


diff --git a/Src/Modules/zpty.c b/Src/Modules/zpty.c
index fca0cc1..d119658 100644
--- a/Src/Modules/zpty.c
+++ b/Src/Modules/zpty.c
@@ -510,14 +510,14 @@ checkptycmd(Ptycmd cmd)
 
     if (cmd->read != -1 || cmd->fin)
 	return;
-    if ((r = read(cmd->fd, &c, 1)) < 0) {
+    if ((r = read(cmd->fd, &c, 1)) <= 0) {
 	if (kill(cmd->pid, 0) < 0) {
 	    cmd->fin = 1;
 	    zclose(cmd->fd);
 	}
 	return;
     }
-    if (r) cmd->read = (int) c;
+    cmd->read = (int) c;
 }
 
 static int