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@xxxxxxx>
* 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]
--
Marco Roeland
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html