Re: [Breakage] 2.20.0-rc0 t1404: test_i18ngrep reports 1 instead of 0 on NonStop in one case
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 11, 2019, 21:07 UTC
- Message-ID
- <xmqqftsughks.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <CACsJy8Bn+2zY6y_QqCjbB3qWM-F=3d0H5vgWj4az=md2FZ8RhA@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
Show 11 quoted lines
> On Mon, Feb 11, 2019 at 2:09 AM Randall S. Becker > <rsbecker@nexbridge.com> wrote: >> >> Hi All, >> >> I tracked down a breakage in t1404 subtest 52. The line >> >> test_i18ngrep "Unable to create $Q.*packed-refs.lock$Q: File exists" err > > The message does not match, does it? Here we grep for "File exists" > but the message you showed says "File already exists".
Hmph, this is from strerror(), right?
The question is if we should be using grep to match on strerror() result in the C locale. Do we really care that the reason of the failure is due to EEXIST for this particular test?
Show 7 quoted lines
>> The verbose output, with diagnostics, is: >> >> error: 'grep Unable to create '.*packed-refs.lock': File exists err' didn't >> find a match in: >> error: Unable to create '/home/git/git/t/trash >> directory.t1404-update-ref-errors/.git/packed-refs.lock': File already >> exists.
Otherwise, perhaps we should loosen the grep pattern, not as a part of "NonStop fix" topic, but as "tests should not depend on having a canonical spelling of strerror() result even in C locale" topic.