Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Completion bug introduced in 3.0.3
- X-seq: zsh-workers 3335
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: Zoltan Hidvegi <hzoli@xxxxxxxxxxxxxxx>, Ingo.Wilken@xxxxxxxxxxxxxxxxxxxxxxxxxxx (Ingo Wilken), zsh-workers@xxxxxxxxxxxxxxx
- Subject: Re: Completion bug introduced in 3.0.3
- Date: Tue, 1 Jul 1997 23:10:18 -0700
- In-reply-to: <199707020451.AAA10907@xxxxxxxxxx>
- References: <199707020451.AAA10907@xxxxxxxxxx>
On Jul 2, 12:51am, Zoltan Hidvegi wrote:
} Subject: Re: Completion bug introduced in 3.0.3
}
} > Another thing: I use a TCL script that sets its stdout stream to
} > non-blocking. This somehow affects zsh, as all interactive commands
} > started after the TCL script (like "ftp" or "more") immediately terminate
I meant to mention this before ...
It's an extremely bad idea for any program to set a tty device for non-
blocking I/O. This doesn't "somehow affect zsh," it affects the modes
of the file descriptor associated with the tty; which happens to be a
dup of the one zsh continues using for future processes, and therefore
it affects those processes as well.
I don't know why bash and tcsh don't show the problem -- either they are
explicitly resetting the blocking state, or they are using a different
scheme for setting up the stdin/out/err descriptors when they create
children. (It's possible that they're using /dev/fd/ or /proc/$$/fd/
rather than dup().)
I don't think ttyctl -f is going to have any effect on this, because the
non-blocking I/O ioctl isn't one that's done through the tty driver
structures; a quick grep through the zsh sources doesn't reveal any
likely-looking calls.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Messages sorted by:
Reverse Date,
Date,
Thread,
Author