Re: [PATCH 29/29] t/test-lib: teach --chain-lint to detect broken &&-chains in subshells

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Jun 26, 2018, 21:42 UTC
Message-ID: <CAPig+cTc2XVX18ocv6ALOSA2CwM8aQLWW+mRWL6Pj1Wu_QHDHw@mail.gmail.com>
In-Reply-To: <CABPp-BGP2OFYgP5Xm0PMj_NPH2f_UmtMpoHYzcgo544V0e-_Zg@mail.gmail.com>

On Tue, Jun 26, 2018 at 5:33 PM Elijah Newren <newren@gmail.com> wrote:

Show 10 quoted lines

> On Tue, Jun 26, 2018 at 1:22 PM, Jeff King <peff@peff.net> wrote:
> > Another option is to not enable this slightly-more-dangerous linting by
> > default. But that would probably rob it of its usefulness, since it
> > would just fall to some brave soul to later crank up the linting and fix
> > everybody else's mistakes.
>
> This may be a dumb question, but why can't we run under errexit?  If
> we could do that, we wouldn't need the &&-chaining, and bash would
> parse the shell for us and exit whenever one command failed.  (Is the
> reason for this documented somewhere?  I couldn't find it...)

I'm not sure if it's documented anywhere, but it has been discussed. In particular, see [1], especially [2], and [3]. Peff summed up by saying:

    So I dunno. I think "set -e" is kind of a dangerous lure. It works
    so well _most_ of the time that you start to rely on it, but it
    really does have some funny corner cases (even on modern shells,
    and for all I know, the behavior above is mandated by POSIX).

[1]: https://public-inbox.org/git/xmqq384zha6s.fsf@gitster.dls.corp.google.com/ [2]: https://public-inbox.org/git/20150320172406.GA15172@peff.net/ [3]: https://public-inbox.org/git/xmqqoannfu84.fsf@gitster.dls.corp.google.com/