On February 11, 2019 16:07, Junio C Hamano wrote: > Duy Nguyen <pclo...@gmail.com> writes: > > > On Mon, Feb 11, 2019 at 2:09 AM Randall S. Becker > > <rsbec...@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.
