zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <pws@csr.com>
To: zsh-workers@sunsite.dk (Zsh hackers list)
Subject: Re: PATCH: exit status
Date: Fri, 10 Nov 2006 16:09:10 +0000	[thread overview]
Message-ID: <200611101609.kAAG9ArT019938@news01.csr.com> (raw)
In-Reply-To: <061110075808.ZM4615@torch.brasslantern.com>

Bart Schaefer wrote:
> On Nov 10,  9:40am, Peter Stephenson wrote:
> }
> } A thread on the Austin group suggests the exit status of the shell
> } should be available in exit traps.
> 
> I'm leaning towards Don Cragun's camp (the prior-to-this-patch zsh
> behavior) on this one.

I can see arguments for both sides; it turns whether you consider the
"exit" command itself to have been executed before the exit traps run,
which is a bit Zen-like.  What finally convinced me is that knowing the
exit status in $? is potentially useful; knowing the status of whatever
command happened to run before is very unlikely to be.  In other
words, if we *do* leave it the old way it simply means the status isn't
useful.

> I think the answer (and a general issue about
> the new hook functions, incidentally) is tied to the answer to this
> other question:
> 
> What is the final exit status of the shell when the exit trap itself
> calls exit?
> 
> If
> 	trap 'exit 42' EXIT; exit 1
> 
> returns 42 to the calling environment, then Korn and the GNU guys are
> correct.  If it exits 1, then Don Cragun is correct.
> 
> Similarly, what happens if the zshexit hook calls exit?  What happens
> if the zshexit hook calls "return 37"?

I alluded to this briefly: hooks and traps run in special contexts which
don't alter the global status.  This has been the case for some time
(though I don't think it was originally like that---early versions were
fairly wayward about return statuses).  That's required in some specific
cases --- the DEBUG trap would be unusable (or at least need extreme
care in writing) if its status were returned to the main shell.  Also,
if we have multiple exit hooks and want them to get the same status
(since they shouldn't care about previous hooks) we need their return
statuses to be protected.  That's how it currently works.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php


  reply	other threads:[~2006-11-10 16:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-10  9:40 Peter Stephenson
2006-11-10 15:58 ` Bart Schaefer
2006-11-10 16:09   ` Peter Stephenson [this message]
2006-11-11  5:28     ` Bart Schaefer
2006-11-11 13:13       ` Peter Stephenson

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=200611101609.kAAG9ArT019938@news01.csr.com \
    --to=pws@csr.com \
    --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).