RE: [Breakage] 2.20.0-rc0 t1404: test_i18ngrep reports 1 instead of 0 on NonStop in one case

["Randall S. Becker" <rsbecker@nexbridge.com>]

On February 11, 2019 16:07, Junio C Hamano wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
> 
> > 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?

You can reasonably expect that NonStop error messages deviate occasionally.
Scaping from strerror() is not a good plan. A worse plan is to use errno
values, which I can guarantee do not match, but that's just an FYI.

> 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?
> 
> >> 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.

I'm happy not to have the fix I supplied used if there's a better way.