Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH (?): Re: suspend while loop.
- X-seq: zsh-workers 11463
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: PATCH (?): Re: suspend while loop.
- Date: Fri, 19 May 2000 09:43:22 +0200 (MET DST)
- In-reply-to: "Bart Schaefer"'s message of Thu, 18 May 2000 16:53:54 +0000
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
Bart Schaefer wrote:
> ...
>
> It's particularly ugly that you can't ^C out of the loop after the ^Z.
> The shell should not hang uninterrupibly unless the user has really
> wrapped a figurative rope around its figurative neck.
Yep, that's what I was thinking (more or less ;-).
> Does anyone see any problems with the following compromise patch?
It's at least a whole lot better than the previous state.
> ...
>
> The thing that most worries me is that zread() can invoke zle, which can
> invoke shell functions, which ....
No, it only uses getkey() which doesn't call functions. It's just a
read-one-char that works while zle is active. But it should be
possible to avoid the child_unblock() when `izle != 0', I think.
What I was worried about are complicated jobs with loops and
suspending, but the job-control-tests still work.
> Another question is, is there a more generic way to do this that covers all
> builtin commands and not just `read'? Or is `read' really the only one
> that needs it?
I can't think of another one right now. We only have to handle
builtins that can potentially block indefinitely, right? (vared comes
to mind, but that can't be used in such a pipe...)
Bye
Sven
--
Sven Wischnowsky wischnow@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author