zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Clint Adams <schizo@debian.org>
Cc: zsh-workers@sunsite.dk, 288323-forwarded@bugs.debian.org,
	288323-submitter@bugs.debian.org
Subject: Re: and lists and suspended processes
Date: Mon, 3 Jan 2005 10:19:34 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.61.0501030945070.32450@toltec.zanshin.com> (raw)
In-Reply-To: <20050103041512.GA22489@scowler.net>

On Sun, 2 Jan 2005, Clint Adams wrote:

> Should zsh wait for a suspended process to exit before continuing along
> the sublist?

I believe I was involved in a related discussion not that long ago.  
Trouble is, I can't recall if it was on zsh-workers or austin-group or 
somewhere else, and searching the zsh archives isn't helping me.

The short answer is, no, zsh can't wait for the suspended process to exit.

Given "one && two && three", if "two" stops, the shell has three choices:
(1) pretend the command was "{ one && two && three }" and suspend the 
    entire sublist; or
(2) pretend that "two" has returned a status and continue the junction; or
(3) stop the entire shell until "two" is resumed.

Choice (1) is undesirable because it subverts the user's intent (if he 
meant there to be braces, he should have typed them) and it puts "three" 
into a separate process when it might better have been run in the current 
shell.  Choice (3) is impossible in an interactive shell.  That leaves 
(2), which is what zsh does, using the signal number as the status.

If there's a bug, it's that zsh returns $? == 20 rather than $? == 148.
I forget why that's done -- maybe it's a compromise because $? > 127 would
indicate the signal caused the child to exit, which is not the case here.


      reply	other threads:[~2005-01-03 18:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-03  4:15 Clint Adams
2005-01-03 18:19 ` 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=Pine.LNX.4.61.0501030945070.32450@toltec.zanshin.com \
    --to=schaefer@brasslantern.com \
    --cc=288323-forwarded@bugs.debian.org \
    --cc=288323-submitter@bugs.debian.org \
    --cc=schizo@debian.org \
    --cc=zsh-workers@sunsite.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).