Re: [RFC PATCH] bisect run: allow inverting meaning of exit code

From: Stephen Oberholtzer <stevie@qrpff.net>
Date: Jan 7, 2020, 00:10 UTC
Message-ID: <CAD_xR9dGNKdVNzFgFUaZCgJetpW5tXxb8wERovdjbc=1jS-KxA@mail.gmail.com>
In-Reply-To: <xmqqy2ul9yg0.fsf@gitster-ct.c.googlers.com>

Junio,

On Sun, Jan 5, 2020 at 8:16 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 14 quoted lines

>
> Yeah, I know.  I didn't mean to give you a perfect solution and that
> was why I said "along the line of...".  I know I ignored the 128 and
> above, as I usually trust that our contributors are competent enough
> to be able to fill in the missing details given an outline.
>
> The key takeaway I wanted you to notice was that a single case
> statement that maps the exit code external command would give us
> would look sufficient, without any of the {SUCCESS,FAIL}_TERM magic
> you had in your version, which indicates that there is more than the
> simple "using a run script to find where a bug was fixed can be done
> by swapping exit code" going on.  And it is quite unclear why that
> is needed either from the patch or the text that accompanied the
> patch.

In this particular instance at least, I'm not competent enough to come up with a clean, portable way to create a single case statement that handles the final condition. The issue I'm having is that case-esac blocks do string matching, not integer value matching, so I don't know how to replicate the current behavior without a case pattern that looks like [12]|1[3-9]|1[01][0-9]|12[0-467]|1[3-9]|2[0-9]|[3-9].

-- 
-- Stevie-O
Real programmers use COPY CON PROGRAM.EXE