From: Jeff King <peff@peff.net>
To: "Randall S. Becker" <rsbecker@nexbridge.com>
Cc: 'Junio C Hamano' <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [ANNOUNCE] Git v2.33.0-rc2 (Build/Test Report)
Date: Mon, 16 Aug 2021 18:22:59 -0400 [thread overview]
Message-ID: <YRrlQwLENaWs8zWm@coredump.intra.peff.net> (raw)
In-Reply-To: <01d001d792e9$55f45470$01dcfd50$@nexbridge.com>
On Mon, Aug 16, 2021 at 05:54:44PM -0400, Randall S. Becker wrote:
> Running git-send-email reports completion 162. The code variable is
> optimized out but looks like it also is 162 when returning. The
> WIFEXITED(status) code did not appear to execute, although I think
> that also was optimized out. finish_command ret is 162. So perl looks
> like it is completing with a bad completion code. This percolates up
> to git, which also reports the same value.
OK, at least that absolves git.c. :)
> I went to the perl maintainer on this subject. What I got back was
> that die is not guaranteed to return a specific value other than 0 for
> success and non-zero for failure. There are platforms where the return
> might known and has meaning but that is not portable. According to the
> current official perl documentation:
>
> "die raises an exception. Inside an eval the exception is stuffed into
> $@ and the eval is terminated with the undefined value. If the
> exception is outside of all enclosing evals, then the uncaught
> exception is printed to STDERR and perl exits with an exit code
> indicating failure. If you need to exit the process with a specific
> exit code, see exit."
Ouch. I mean, sure, if you need a specific code, I get that die is not a
good tool. But getting arbitrary values seems kind of weird and
unfriendly. The perldoc for die does say it gives you $! (errno), or $?
(the last child exit value) if appropriate. So it's not completely
arbitrary, but I think your errno value may just be unlucky.
> So assuming that a signal occurred because the value is between 129
> and 192 is not correct in the case of perl. Could we do something like
> test_expect_perl_die that does not perform the signal check at line
> 980 in test-lib-functions.sh so just checks 0 vs. non-zero, which
> would be semantically correct no matter what the platform?
> Alternatively, and possibly better, the die could be caught and then
> exit() called in git-send-email, as in:
>
> eval { die "Something bad happened" };
> exit(255) if $@;
Yeah, I think we are better to get a consistent exit code from perl.
There are a few options here:
- wrapping in an eval works, as you showed above. It's a little awkward
to wrap the whole script, though.
- there's $SIG{__DIE__}, but the manpage warns against using it. You
can use it something like this:
sub catch_top {
CORE::die @_ if $^S; # in an eval; use regular die
CORE::die @_ if !defined $^S; in perl's parser
print STDERR "@_\n";
exit 255; # or whatever we want
}
$SIG{__DIE__} = \&catch_top;
- you can hook die() like this:
BEGIN { *CORE::GLOBAL::die = \&my_die; }
but I expect would still need to check that you're not in an eval, as
above.
- The SIG{__DIE__} docs mention using an END{} block, but I'm not sure
how you determine if we hit a die or not (at that point, $@ won't
actually be set).
I've used the catch_top() thing before and it does work (it's just ugly
that you have to deal with $^S).
I guess yet another alternative is that we could avoid using perl's
die() in favor of our own custom-named function. It seems like that may
confuse folks who come later, though.
-Peff
next prev parent reply other threads:[~2021-08-16 22:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-13 14:22 [ANNOUNCE] Git v2.33.0-rc2 (Build/Test Report) Randall S. Becker
2021-08-13 15:00 ` Junio C Hamano
2021-08-13 16:06 ` Jeff King
2021-08-16 18:08 ` Randall S. Becker
2021-08-16 18:35 ` Jeff King
2021-08-16 18:54 ` Randall S. Becker
2021-08-16 21:55 ` Jeff King
2021-08-16 21:59 ` Jeff King
2021-08-16 18:31 ` Randall S. Becker
2021-08-16 18:36 ` Jeff King
2021-08-16 20:43 ` Randall S. Becker
2021-08-16 21:02 ` Jeff King
2021-08-16 21:54 ` Randall S. Becker
2021-08-16 22:22 ` Jeff King [this message]
2021-08-16 22:29 ` Jeff King
2021-08-17 14:30 ` Randall S. Becker
2021-08-17 14:29 ` Randall S. Becker
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YRrlQwLENaWs8zWm@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=rsbecker@nexbridge.com \
/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://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).