From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-workers@sunsite.auc.dk
Subject: Re: pws-22: killing the ZSH loops problem
Date: Fri, 18 Jun 1999 16:44:43 +0000 [thread overview]
Message-ID: <990618164443.ZM8127@candle.brasslantern.com> (raw)
In-Reply-To: <199906180855.KAA12796@beta.informatik.hu-berlin.de>
In-Reply-To: <000a01beb99f$e3c28fb0$21c9ca95@mow.siemens.ru>
On Jun 18, 10:55am, Sven Wischnowsky wrote:
} Subject: Re: pws-22: killing the ZSH loops problem
}
} Unless I'm missing something obvious, we can't simply execute
} processes in a loop (or other shell construct) in the same pgrp as the
} shell. Sure, this would give us the SIGINT, but it would also give us
} the SIGSTOP -- suspending the shell.
Strictly speaking, it would give us SIGTSTP -- ^Z does not generate STOP.
Since TSTP is catchable (unlike STOP), the parent shell simply has to have
a TSTP handler or ignore TSTP -- which zsh already does.
Incidentally, and probably not strictly a zsh thing, `kill -STOP $$` in an
xterm locks up the whole xterm (it won't even repaint itself or bring up
the ctrl-buttonN menus) and closing the xterm with the window manager
orphans the shell even if you've restarted it with `kill -CONT ...` from
somewhere else. I had to `kill -9 ...` it.
On Jun 18, 7:33pm, Andrej Borsenkow wrote:
} Subject: RE: pws-22: killing the ZSH loops problem
}
} > (Btw. `foo | while ...' can be ^C'ed because we have the `foo' to find
} > that out. This means that we could make normal loops be ^C'able by
} > forking of a sub-shell for every loop and let the sub-shell do
} > nothing. Then ^C would SIGINT the sub-shell and the parent shell would
} > be notified about this -- but this is really ugly isn't it? Or should
} > we? But that would be an extra fork on every shell construct...)
}
} We need it only if MONITOR is set
Not true! MONITOR only affects handling of ^Z, not of ^C. We need to be
able to properly interrupt such loops in any shell.
However, we only need it when (a) there's at least one external command
(you can already interrupt purely builtin loops, try it) and (b) that
external command doesn't return the proper exit status for zsh to learn
that it caught a signal. We can't know (b) in advance, so I can't come
up with anything useful for (a) except to fork twice on every external
command, which is horribly wasteful.
} And it just occured to me - is it possible to kill/stop/resume shell
} function?
Yes. In fact, that was the recommended workaround for several pipe-into-
a-loop problems before they gradually got fixed: Put the loop in a shell
function and pipe to the function. That's still the best way to minimize
the number of processes that get forked (there was a thread about this a
while back, perhaps as much as a year ago).
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
next prev parent reply other threads:[~1999-06-18 16:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-06-18 8:55 Sven Wischnowsky
1999-06-18 15:33 ` Andrej Borsenkow
1999-06-18 16:44 ` Bart Schaefer [this message]
1999-06-21 7:08 ` Andrej Borsenkow
1999-06-21 15:55 ` Bart Schaefer
1999-06-21 16:14 ` Andrej Borsenkow
-- strict thread matches above, loose matches on Subject: below --
1999-06-21 11:29 Sven Wischnowsky
1999-06-17 9:23 Sven Wischnowsky
1999-06-16 9:09 Andrej Borsenkow
1999-06-16 8:43 Andrej Borsenkow
1999-06-15 16:45 Andrej Borsenkow
1999-06-16 15:14 ` Peter Stephenson
1999-06-16 17:16 ` Bart Schaefer
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=990618164443.ZM8127@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=zsh-workers@sunsite.auc.dk \
/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).