[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: return exit code in EXIT trap

From: Robert E. Griffith
Subject: Re: return exit code in EXIT trap
Date: Sat, 6 Aug 2022 12:02:07 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

Hmmm.. I just got confused when I went to do a test...

   $ trap 'echo hi; return' SIGUSR2
   $ kill -SIGUSR2 $$
   bash: return: can only `return' from a function or sourced script
   $ $ echo $BASH_VERSION

I also confirmed the same error in the DEBUG trap where you specifically do need to set the exit code.

I realize now that in my scripts I use a function 'setExitCode() { return $?; }'  function in traps as a stand in for 'return'.

Where can we use 'return' directly in a trap script? What am I not getting?


On 8/6/22 00:05, Robert Elz wrote:
I am actually astounded by all of this - both by what is in the
standard, and the way Chet interpreted it.

The language in the standard for return was clearly based upon the
idea that it should act just the same as exit, which is not really

Even at first glance, an "exit" executed anywhere (not really, but I'll
get to that below) in the trap handler causes the shell to exit - and it
is reasonable, when no specific exit code is given, for exit to default
to the status just before the trap fired (though even that isn't as well
defined as it should be).    Return is nothing like that - it isn't even
clear that it is specified (not even when the trap fires when a function is
running) that a return in the trap handler can do any more then cause the
function it is lexically defined within to return (which does not mean the
function that happened to be running at the time).   That to me looks
unspecified (in at least the latest wording).

Even exit should not arbitrarily default to the exit code before the trap
started - that should only apply to instances of exit which cause the shell
invoking the trap to actually exit, not ones in some sub-shell which only
cause that sub-shell to exit, or even worse, an entirely different shell,

        trap "$OTHERSHELL -c 'grep pattern /some/file >/dev/null ; exit'" SIG

where OTHERSHELL is not necessarily even the same command as the one
running the trap command (consider one is bash, the other is dash) - but
from the language, as it is, in the standard, that exit is in a trap handler,
so should exit with the status the other shell had before the trap was

That's patently absurd, and not only does no shell implement that, there is
no mechanism by which it could (no way to invoke OTHERSHELL and tell it what
the exit status was in the invoking shell).

The language in POSIX is clearly broken, and needs fixing.  What's kind of
amazing is that none of the "primary" austin group people made any responses
at all to the mailing list discussion.

Clearly this needs a posix defect report filed, if no-one else does that
today, I probably will.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]