Hello list!
Recently test t4118 was added to prepare for upcoming changes in behaviour of GNU diff.
This test fails on Mac OS X. It turns out that in the end the failure comes from a difference in the behaviour between GNU sed and the version that comes with OS X.
The feature that is tested works fine, but the implementation of the examination of the result fails.
The difference is that the OS X version of sed always ends the last line with a newline character, even if it wasn't there in the input. Strictly speaking this is POSIX specified behaviour that was changed in the GNU version of sed in 1997, citing from the changelog for the historically curious minded people:
Mon Jul 28 10:50:41 PDT 1997 Ken Pizzini <ken@gnu.org>
* sed.c, sed.h, execute.c: POSIX.2, section 4.55.7, says that
a newline must end *every* output line. But I think
that it is useful (when seding a binary file) to omit
a trailing newline if the input lacks one. Thus the addition of
POSIXLY_CORRECT behavior.* execute.c: however, when seding multiple files my feeling
is that it makes sense to have each file but the last
behave as-if it ended in a newline. Modified read_pattern_space()
accordingly.A workaround on Mac OS X is easy by for example just installing the GNU version of sed from the 'fink' archive with "sudo apt-get install sed". Funny enough the system 'diff' is already the GNU version, so the test t4118 itself might even be necessary for upcoming feline versions of OS X!
Unfortunately I myself don't see an elegant and portable fix in the test itself... [hint]