Zsh Mailing List Archive
Messages sorted by:
Re: Terminal I/O handling fix
- X-seq: zsh-workers 38
- From: Richard Coleman <coleman@xxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxxx
- Subject: Re: Terminal I/O handling fix
- Date: Thu, 25 May 1995 20:34:48 -0400
- In-reply-to: Your message of "Tue, 23 May 1995 16:16:25 BST." <29387.9505231516@xxxxxxxxxxxxxxx>
> This is an updated form of a patch I posted some time ago which was
> just too late to make it into zsh 2.4 (and which had some problems
> with select() which I later fixed). It separates the I/O of zle from
> direct reliance on stdin/stdout or FD's 0 and 1.
This is a change that is definitely needed. The mishandling of
internal fd's seems to be the source of most of zsh's worst
(in the sense of being the hardest to fix) bugs.
> The difficult case is `exec < file' since that's supposed to change
> where commands are being read from. In fact, if zle was being used,
> it always attempted to use zle to read from the file. I've put an
> explicit test in execcmd() for this, so that if commands are
> notionally coming from stdin in an interactive shell and you do 'exec
> < file' it tries to work out what to do. The case where `file' is
> actually a terminal is the hardest, since then there's in principle a
> lot more work to do. In fact, all I've done is re-open the terminal
> files (so that exec <$TTY to fix up your terminal works like it always
> did, in fact now it always makes editing work sensibly which it didn't
> before when stdout was also used). Ideally this probably needs to be
> more sophisticated, or combined with the code in setmoreflags() which
> sets up terminal handling initially. (At the moment that does other
> things, which is why I didn't use it.)
This is the part that I like the least. I'm wary of adding more tricky
logic to exec.c since it's basically incomprehensible already. I've
started a little cleanup of the tty initialization in setmoreflags in
beta9-test5 (which unfortunately causes your patch to fail, but it
is easy to fix by hand). What type of things would need to be added
here to fix the problems you are talking about. I guess I don't
understand the issues involved.
> I'd have liked to make this patch smaller, but the central problem is
> that zle is not well separated from the other parts of zsh. That's
> what's necessitated the extra couple of chunks of code. It's quite
> possible there are some remaining anomalies between stdout/shout.
The zle code could definitely stand to be modularized a bit. I'm open
to suggestions and/or patches on how to clean this up.
This go for the rest of zsh. If anyone has suggestions on how to
restructure/cleanup parts of the code, let me know. This can
include adding comments, moving functions from one file to another,
or whatever. Of course this doesn't fix any bugs, but anything to
improve the readability of the code will help maintainability.
Messages sorted by: