From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16001 invoked from network); 9 Apr 2004 22:51:16 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 9 Apr 2004 22:51:16 -0000 Received: (qmail 25419 invoked by alias); 9 Apr 2004 22:51:07 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19750 Received: (qmail 25348 invoked from network); 9 Apr 2004 22:51:07 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 9 Apr 2004 22:51:07 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [130.225.247.86] by sunsite.dk (MessageWall 1.0.8) with SMTP; 9 Apr 2004 22:51:7 -0000 Received: (qmail 4711 invoked from network); 9 Apr 2004 22:51:07 -0000 Received: from moonbase.zanshin.com (167.160.213.139) by a.mx.sunsite.dk with SMTP; 9 Apr 2004 22:51:05 -0000 Received: from aztec.zanshin.com (IDENT:schaefer@aztec.zanshin.com [167.160.213.132]) by moonbase.zanshin.com (8.12.11/8.12.11) with ESMTP id i39Mp13I007595 for ; Fri, 9 Apr 2004 15:51:01 -0700 Date: Fri, 9 Apr 2004 15:51:01 -0700 (PDT) From: Bart Schaefer To: zsh-workers@sunsite.dk Subject: Strange problem with zsh on RedHat Enterprise Linux Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, hits=0.0 required=6.0 tests=none autolearn=no version=2.63 X-Spam-Hits: 0.0 More specifically, on CentOS 3.1 (www.centos.org). Zsh _always_ forces the "monitor" option to be off when run in a terminal emulator or even when logging in remotely with ssh. This is a royal pain. It affects both the CentOS zsh RPM (4.0.7) and a fresh build from CVS. For some reason, tcsetpgrp(SHTTY, pgrp) is returning -1 in attachtty() even though the current process group is already the same as pgrp. It appears to set (or leave unset) errno = 0 even though it "failed," but I'm not sure I can trust what the debugger is reporting as the value of errno, because the errno != ENOTTY branch is not taken (no zwarn output). In any case, this causes us to hit this branch of the code: if (pgrp != mypgrp && kill(-pgrp, 0) == -1) attachtty(mypgrp); else { if (errno != ENOTTY) { zwarn("can't set tty pgrp: %e", NULL, errno); fflush(stderr); } opts[MONITOR] = 0; ep = 1; } Well, pgrp != mypgrp is false, so we hit the "else" branch without ever attempting the kill(), and needlessly turn off opts[MONITOR]. Argh. At this point isset(MONITOR) is false so the "if (jobbing)" around the entire body of attachtty() is false and we can never try to attach to the terminal again. So I changed it like this ... opts[MONITOR] = (gettygrp() == pgrp); ep = !opts[MONITOR]; ... and now all is well. However, any explanation of why tcsetpgrp() is "failing" in this strange way would be appreciated. However ... one other thing, even stranger. If I actually comment out the "if (errno != ENOTTY)" to force zwarn to print something, I first get "inappropriate ioctl for device" and then zsh goes into an infinite loop, calling attachtty() repeatedly but never again zwarn()ing any output (even though zwarn() IS being called, so "noerrs" must have become set). glibc-2.3.2-95.6 gcc-3.2.3-24