Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Confirming X02zlevi test failures
- X-seq: zsh-workers 33743
- From: Oliver Kiddle <okiddle@xxxxxxxxxxx>
- To: Zsh workers <zsh-workers@xxxxxxx>
- Subject: Re: Confirming X02zlevi test failures
- Date: Fri, 21 Nov 2014 15:37:17 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1416591277; bh=pJwwSt8jO/T1ZwkQvO0QG/xXFq62zBoNDbzn7lSPAx8=; h=In-reply-to:From:References:To:Subject:Date:From:Subject; b=KcJpUFk8URAioRMaALLcGcShoDe+Fcvq8ZwM01bbILaoqqnECU3YPMeb/ebcsZ54ldLU/oKBr46Gtff8Pfg/Ilptxo1nGrWijfSna/m8Ks762nZ2j78CK5WpwGQ7Ov5JFw7+MpTT8vXOsw97HIP1dZyBuEpS0Mwa2oz3hO7EsXZ5FaknGe6XeUOapSwZzUBiNISm7sWQ6t4Q75qt5a/yzQOgb4ONpMYvIJZmjrdG7UoJtc4fWDR7bZnuThp2a1EiVwnbR9JqTjNEiX9/Jg1szRtUAtE3/HRtvXXFtZjLyNd4MLGtA4PPHgoZWWVpdf0hln85d644M4C+TvsRYXvbDg==
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.co.uk; b=eq5fAnKwfXWCP549D61E3iciPEyvHJ6hy2iu3lxcpev9gQsI5th7uZV66UcXHl7gBPTHz34avoYySUUzdZJAbP5FdT6iB2n6uM87I0VSdBPkbZKsIQdV3lDgUakWiKoBtOZNcrUPnxRyp0cwj96EXC/0H1Pyar+A7uB9LoeTW5N5vof9GVwR93vkwzebWVPc73/th9x+ryQEmblCQOBHJSU6nJNczBR4mq2PzXbvowjrLb2zjQtxVJrPFady8dj7AeNXbmscnowWedIvgOPaENhMQzsNHjAJ/jBpsG6Fik55ly8ucgo9Viq5Qhbi60A5oqO3KYS+GdZxmFDXXoh4cQ==;
- In-reply-to: <141120091803.ZM3693@torch.brasslantern.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <141119085006.ZM18951@torch.brasslantern.com> <11014.1416438322@quattro> <141119222019.ZM2717@torch.brasslantern.com> <5A1A98B7-42E0-4EE1-9468-32E2D6434246@kba.biglobe.ne.jp> <141120091803.ZM3693@torch.brasslantern.com>
Bart wrote:
>
> I begin to suspect that what needs to happen is that zpty needs to be a
> lot more aggressive internally about consuming (and buffering up) the
> slave output as fast as it appears, even if a zpty read call has not
> yet been made from the shell. Clearly the slave can "see" it's own
> output if the master doesn't manage to grab it first.
That might be worth a try.
I tried the following change to see if it would have an effect.
It results in zpty getting a device such as /dev/pts/2 instead of
/dev/ttyp0 on FreeBSD. I suspect it might also avoid the need to kldload
pty but would need to reboot a remote machine to confirm. So I think it
is useful anyway. Unfortunately it has no effect on the bug.
Oliver
diff --git a/Src/Modules/zpty.c b/Src/Modules/zpty.c
index d119658..63c79a7 100644
--- a/Src/Modules/zpty.c
+++ b/Src/Modules/zpty.c
@@ -189,7 +189,11 @@ get_pty(int master, int *retfd)
#endif
if (master) {
+#ifdef HAVE_POSIX_OPENPT
+ if ((mfd = posix_openpt(O_RDWR|O_NOCTTY)) < 0)
+#else
if ((mfd = open("/dev/ptmx", O_RDWR|O_NOCTTY)) < 0)
+#endif
return 1;
if (grantpt(mfd) || unlockpt(mfd) || !(name = ptsname(mfd))) {
diff --git a/configure.ac b/configure.ac
index 306a005..56c4cfb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1291,6 +1291,7 @@ AC_CHECK_FUNCS(strftime strptime mktime timelocal \
pcre_compile pcre_study pcre_exec \
nl_langinfo \
erand48 open_memstream \
+ posix_openpt \
wctomb iconv \
grantpt unlockpt ptsname \
htons ntohs \
Messages sorted by:
Reverse Date,
Date,
Thread,
Author