On Thu, Aug 23, 2018 at 2:02 PM Ævar Arnfjörð Bjarmason
wrote:
> Found in some 2.19 testing on AIX:
Thanks for reporting these issues.
> > + /^[ ]*EOF[ ]*$/!bhereslurp
>
> AIX sed doesn't like this, and will yell:
> :hereslurp is greater than eight characters
> This on top fixes
On Wed, Jul 11 2018, Eric Sunshine wrote:
Found in some 2.19 testing on AIX:
> +# here-doc -- swallow it to avoid false hits within its body (but keep the
> +# command to which it was attached)
> +/<<[ ]*[-\\]*EOF[]*/ {
> + s/[ ]*<<[ ]*[-\\]*EOF//
> + h
> +
On Tue, Jul 31, 2018 at 02:55:51PM -0400, Eric Sunshine wrote:
> > I hesitate to make any suggestion here, as I think we may have passed
> > a point of useful cost/benefit in sinking more time into this script.
> > But...is switching to awk or perl an option? Our test suite already
> > depends on
On Tue, Jul 31, 2018 at 8:50 AM Jeff King wrote:
> On Mon, Jul 30, 2018 at 05:38:06PM -0400, Eric Sunshine wrote:
> > I considered that, but it doesn't handle nested here-docs, which we
> > actually have in the test suite. For instance, from t9300-fast-import:
> > [...]
> > Nesting could be
On Mon, Jul 30, 2018 at 05:38:06PM -0400, Eric Sunshine wrote:
> > I wonder if it should look for something like [A-Z][A-Z_]* to catch
> > all of these.
>
> I considered that, but it doesn't handle nested here-docs, which we
> actually have in the test suite. For instance, from
On Mon, Jul 30, 2018 at 4:59 PM Jonathan Nieder wrote:
> Eric Sunshine wrote:
> > The subshell linter would normally fold out the here-doc content, but
> > 'sed' isn't a proper programming language, so the linter can't
> > recognize arbitrary here-doc tags. Instead it has hard-coded knowledge
> >
Eric Sunshine wrote:
> On Mon, Jul 30, 2018 at 2:14 PM Jonathan Nieder wrote:
>> (
>> chks_sub=$(cat <> $chks
>> TXT
>> ) &&
>>
>> Ugly quoting, useless use of "cat", etc, aside, I don't think it's
>> missing any &&. Hints?
>
> Yes, it's a false positive.
>
> The
On Mon, Jul 30, 2018 at 2:14 PM Jonathan Nieder wrote:
> Eric Sunshine wrote:
> > Address this shortcoming by feeding the body of the test to a
> > lightweight "linter" which can peer inside subshells and identify broken
> > &&-chains by pure textual inspection.
>
> This is causing
(resetting cc list)
Jonathan Nieder wrote:
> This is causing contrib/subtree tests to fail for me: running "make -C
> contrib/subtree test" produces
[...]
> error: bug in the test script: broken &&-chain or run-away HERE-DOC:
[...]
> Ugly quoting, useless use of "cat", etc, aside, I don't
Hi,
Eric Sunshine wrote:
> The --chain-lint option detects broken &&-chains by forcing the test to
> exit early (as the very first step) with a sentinel value. If that
> sentinel is the test's overall exit code, then the &&-chain is intact;
> if not, then the chain is broken. Unfortunately, this
Eric Sunshine writes:
> However, existing tests aside, the more important goal is detecting
> problems in new or updated tests hiding genuine bugs in changes to Git
> itself, so it may have some value.
Yes, indeed.
On Thu, Jul 12, 2018 at 12:56 PM Jeff King wrote:
> Like Junio, I'm a little nervous that this is going to end up being a
> maintenance burden. People may hit false positives and then be
> confronted with this horrible mass of sed to try to figure out what went
> wrong [...]
A very valid
On Thu, Jul 12, 2018 at 06:50:20AM -0400, Eric Sunshine wrote:
> And, perhaps most important: We're not tied indefinitely to the
> "subset" implemented by the current linter. If it is indeed found to
> be too strict or limiting, it can always be loosened or retired
> altogether.
Yeah, I agree
On Wed, Jul 11, 2018 at 5:37 PM Junio C Hamano wrote:
> As with the previous "transform the script and feed the result to
> shell" approach, this risks to force us into writing our tests in a
> subset of valid shell language, which is the primary reason why I
> was not enthused when I saw the
Eric Sunshine writes:
> The --chain-lint option detects broken &&-chains by forcing the test to
> exit early (as the very first step) with a sentinel value. If that
> sentinel is the test's overall exit code, then the &&-chain is intact;
> if not, then the chain is broken. Unfortunately, this
The --chain-lint option detects broken &&-chains by forcing the test to
exit early (as the very first step) with a sentinel value. If that
sentinel is the test's overall exit code, then the &&-chain is intact;
if not, then the chain is broken. Unfortunately, this detection does not
extend to
16 matches
Mail list logo
