From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>,
zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: Misc. zpty tweaks, plus commentary
Date: Mon, 13 Nov 2000 16:20:01 +0000 [thread overview]
Message-ID: <1001113162002.ZM22020@candle.brasslantern.com> (raw)
In-Reply-To: <200011131021.LAA30936@beta.informatik.hu-berlin.de>
On Nov 13, 11:21am, Sven Wischnowsky wrote:
} Subject: Re: PATCH: Misc. zpty tweaks, plus commentary
}
} [ in another message: ]
}
} > This reveals that still another remaining problem is that `zpty -w' on a
} > blocking pty doesn't stop when the process on the pty is killed. There
} > doesn't seem to be any simple fix for this; write() itself is blocked,
} > and does not get interrupted with SIGPIPE as would normally occur.
}
} Hm, yes. There might be a solution using the fact that we have a
} subshell that we could make ignore SIGHUP (and write something to the
} pty or whatever). But I currently can't see how this really helps.
If we kept track of the fact that the process on the pty is one of our
children, we could handle all of this when the SIGCHLD arrives. Modules
need to be able to register handlers for that as much (if not more) than
they need to be able to register I/O handlers.
A simple table mapping PIDs to callbacks would suffice.
} [ and in yet another message: ]
}
} > I haven't done anything about it, but this code clearly expects that
} > no '\0' bytes will ever be sent to or received from the pty. That's
} > obviously a fallacy; we shouldn't be treating this data as C strings.
}
} Yes and no. For reading, this already worked (the call to metafy()).
Lines 467 and 519 sling cmd->old around with strcpy(). The metafy() on
525 only works if there's never been read-ahead.
} > (On my RH5.2 linux system, select() always returns 1 after the pty's
} > command has exited, so read_poll() also returns 1 and cmd->fin never
} > gets set. read(), however, gets an I/O error (errno == 5), so `zpty -r'
} > returns 1 and it's not possible to detect that the command has finished.
}
} Another reason for not using read_poll(), does anyone see a way to
} allow us to find out if a command has exited and still be able to read
} the rest of its output?
The SIGCHLD handler could deal with this, too. (The finding-out part, not
the reading-the-rest part.)
--
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
next prev parent reply other threads:[~2000-11-13 16:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-13 10:21 Sven Wischnowsky
2000-11-13 16:20 ` Bart Schaefer [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-11-04 23:29 Bart Schaefer
2000-11-05 1:59 ` Bart Schaefer
2000-11-05 4:35 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1001113162002.ZM22020@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).