From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: "Sullivan N. Beck" <sbeck@cise.ufl.edu>, zsh-users@sunsite.auc.dk
Subject: Re: Change in suspend behavior
Date: Thu, 10 May 2001 15:35:13 -0700 [thread overview]
Message-ID: <010510153513.ZM24266@candle.brasslantern.com> (raw)
In-Reply-To: <20010510195228.018E6DCC4@mail.cise.ufl.edu>
On May 10, 3:52pm, Sullivan N. Beck wrote:
> Subject: Change in suspend behavior
>
> Using zsh-3.1.5, I would often make use of a feature of zsh.
Strictly speaking, you would abuse a bug in zsh, I'm afraid.
> % for i in foo bar ;do
> for> mycmd $i
> for> done
>
> Then, once "mycmd foo" was running, I could suspend that job with
> 'Ctrl-z', proceed to start up "mycmd bar" and then I would end up with
> two backgrounded jobs
You should be able to get the same effect by doing
for i in bar foo; do mycmd $i & done; wait; fg
The "wait" is just there to be sure that all the jobs have a chance to
start up (and then stop again on SIGTTOU or SIGTTIN) before the "fg"
is executed. If "mycmd" is something that will actually run in the
background, add a "kill -TSTP $! ;" between the ampersand and "done".
> I unpgraded to zsh-3.1.9 (and I also tried zsh-4.0.1-pre4, but the
> behavior is the same there), and instead of suspending "mycmd", it
> suspends the entire for loop.
It also interrupts the entire for-loop if you type control-C; not doing
so was the real bug -- before, a loop like
for i; do something safe; something dangerous; done
would immediately execute something dangerous if something safe were
interrupted or suspended. There was no reliable way to break out of
a loop once it was running. Deterministic behavior is preferable, even
if inconvenient for special cases.
> This seems very bizarre to me (is zsh creating a sub-shell now every
> time it makes a loop?)
No, it waits until it actually receives the SIGTSTP and then forks off
the loop (or the entire shell function if the loop is in a function body).
If you never signal it, it behaves as it always did.
> Is there a config variable I can set to get the original behavior back?
No, sorry (I'm sympathetic, but not apologetic).
prev parent reply other threads:[~2001-05-10 22:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-10 19:52 Sullivan N. Beck
2001-05-10 22:35 ` Bart Schaefer [this message]
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=010510153513.ZM24266@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=sbeck@cise.ufl.edu \
--cc=zsh-users@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).