zsh-workers
 help / color / mirror / code / Atom feed
From: Richard Coleman <coleman@math.gatech.edu>
To: zsh-workers@math.gatech.edu
Subject: Re: Terminal I/O handling fix
Date: Thu, 25 May 1995 20:34:48 -0400	[thread overview]
Message-ID: <9505260034.AA29498@redwood.skiles.gatech.edu> (raw)
In-Reply-To: Your message of "Tue, 23 May 1995 16:16:25 BST." <29387.9505231516@pyro.swan.ac.uk>

> 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.

rc


  reply	other threads:[~1995-05-26  0:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1995-05-23 15:16 P.Stephenson
1995-05-26  0:34 ` Richard Coleman [this message]
1995-05-26 10:10   ` P.Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9505260034.AA29498@redwood.skiles.gatech.edu \
    --to=coleman@math.gatech.edu \
    --cc=zsh-workers@math.gatech.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).