On Fri, Jan 26, 2018 at 01:37:08PM +0100, SZEDER Gábor wrote: > When 'test_i18ngrep' can't find the expected pattern, it exits > completely silently; when its negated form does find the pattern that > shouldn't be there, it prints the matching line(s) but otherwise exits > without any error message. This leaves the developer puzzled about > what could have gone wrong. > > Make 'test_i18ngrep' more informative on failure by printing an error > message including the invoked 'grep' command and the contents of the > file it had to scan through. I think this is an improvement. You can also use "-x" to get a better sense of exactly which command failed, but I have never been sad to see more verbose output from failing tests by default. :) > Note that this "dump the scanned file" part is not quite perfect, as > it dumps only the file specified as the function's last positional > parameter, thus assuming that there is only a single file parameter. > I think that's a reasonable assumption to make, one that holds true in > the current code base. And even if someone were to scan multiple > files at once in the future, the worst thing that could happen is that > the verbose error message won't include the contents of all those > files, only the last one. Alas, we can't really do any better than > this, because checking whether the other positional parameters match a > filename can result in false positives: 't3400-rebase.sh' and > 't3404-rebase-interactive.sh' contain one test each, where the > 'test_i18ngrep's pattern verbatimely matches a file in the trash > directory. Note that the absence of a file parameter is not an issue, > because the lint check added in the previous commit ensures that > 'test_i18ngrep' never reads from its standard input, consequently > there must be a file parameter. Heh, this makes me support even more the "last one must be a file" rule that Junio suggested for the linting check. -Peff
