From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28133 invoked by alias); 17 Sep 2010 16:12:03 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 28268 Received: (qmail 18210 invoked from network); 17 Sep 2010 16:12:00 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <100917091143.ZM31859@torch.brasslantern.com> Date: Fri, 17 Sep 2010 09:11:43 -0700 In-reply-to: <100917074136.ZM31402@torch.brasslantern.com> Comments: In reply to Bart Schaefer "Re: PATCH: coprocess descriptor and error messages" (Sep 17, 7:41am) References: <100916220444.ZM30547@torch.brasslantern.com> <20100917094610.390f120f@pwslap01u.europe.root.pri> <100917074136.ZM31402@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: PATCH: coprocess descriptor and error messages MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Sep 17, 7:41am, Bart Schaefer wrote: } } Aside: Should an interactive shell ever exit on SIGPIPE? Or maybe } a better question is, should a print to the coprocess ever cause an } un-trapped SIGPIPE? Experimenting with pdksh seems to indicate that the equivalent of zsh's coprocout descriptor is closed in the child-exited handler when the coprocess terminates. I don't recall enough about (and didn't yet delve back into) the zsh job table to know if we have enough information to identify the coprocess job at that point. The coprocin descriptor remains open until EOF, as in zsh. } In looking further, the coprocess descriptor is reset to -1 only (and } immediately) by "read -p" detecting EOF on the coprocess output. So } in the "read" case, the invalid descriptor has always served as an } EOF flag. What should happen if the parent attempts to read after } an EOF has been seen? I would tend to think it should just get EOF } again, not produce a diagnostic, which is the current behavior. } } However, ksh (at least pdksh) disagrees with me: Here's a patch that duplicates the pdksh behavior, except for the part about exiting on SIGPIPE if an extra print occurs before all output has been read. Apply this *instead* of the previous patch. Index: builtin.c =================================================================== RCS file: /extra/cvsroot/zsh/zsh-4.0/Src/builtin.c,v retrieving revision 1.48 diff -c -r1.48 builtin.c --- builtin.c 17 Apr 2009 18:57:22 -0000 1.48 +++ builtin.c 17 Sep 2010 15:59:06 -0000 @@ -3677,13 +3720,21 @@ if (OPT_HASARG(ops,'u') || OPT_ISSET(ops,'p')) { int fd; - if (OPT_ISSET(ops, 'p')) + if (OPT_ISSET(ops, 'p')) { fd = coprocout; - else { + if (fd < 0) { + zwarnnam(name, "-p: no coprocess"); + return 1; + } + } else { char *argptr = OPT_ARG(ops,'u'), *eptr; /* Handle undocumented feature that -up worked */ if (!strcmp(argptr, "p")) { fd = coprocout; + if (fd < 0) { + zwarnnam(name, "-p: no coprocess"); + return 1; + } } else { fd = (int)zstrtol(argptr, &eptr, 10); if (*eptr) { @@ -5038,6 +5099,10 @@ /* The old code handled -up, but that was never documented. Still...*/ if (!strcmp(argptr, "p")) { readfd = coprocin; + if (readfd < 0) { + zwarnnam(name, "-p: no coprocess"); + return 1; + } } else { readfd = (int)zstrtol(argptr, &eptr, 10); if (*eptr) { @@ -5052,6 +5117,10 @@ izle = 0; } else if (OPT_ISSET(ops,'p')) { readfd = coprocin; + if (readfd < 0) { + zwarnnam(name, "-p: no coprocess"); + return 1; + } izle = 0; } else readfd = izle = 0;