Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: 3.1.4: flushing input properly
- X-seq: zsh-workers 4173
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>
- To: Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>
- Subject: Re: PATCH: 3.1.4: flushing input properly
- Date: Fri, 26 Jun 1998 09:54:21 -0700
- Cc: zsh-workers@xxxxxxxxxxxxxxx
- In-reply-to: <9806261017.AA25564@xxxxxxxxxxxxxxxxx>
- References: <9806261017.AA25564@xxxxxxxxxxxxxxxxx>
On Jun 26, 12:17pm, Peter Stephenson wrote:
} Subject: PATCH: 3.1.4: flushing input properly
}
} Most of the patch is converting inerrflush() to herrflush(). In fact,
} inerrflush() is now only called from the signal handler, but I wanted
} to alter that as little as possible. I hope nobody was particularly
} attached to discard_input().
This looks good. Just one question ... why does discard_input() clear
and then set errflag, and why doesn't herrflush() need to do the same?
} A slightly different issue: it remains the case that the shell
} blithely ignores parse errors, executing any commands it comes across
Hrm. That's particularly bad given that "zsh -ef" does the same thing.
It at least ought to give up when told to exit on error.
} You might well argue it
} ought to give up on the first error, as ksh does. That needs careful
} handling, though, to distinguish between running scripts, running
} interactively, and sourcing a file.
I believe the reason it behaves as it does is for purposes of sourcing
a file, so that syntax errors in .zshrc et. al. don't cause the entire
init process to fail. That's a nicety I'd rather not give up.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Messages sorted by:
Reverse Date,
Date,
Thread,
Author