Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Strange problem with zsh on RedHat Enterprise Linux
- X-seq: zsh-workers 19750
- From: Bart Schaefer <schaefer@xxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Strange problem with zsh on RedHat Enterprise Linux
- Date: Fri, 9 Apr 2004 15:51:01 -0700 (PDT)
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author