subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Troy Curtis Jr <>
Subject Re: diff --normal is not portable (Re: svn commit: r1824410 - in /subversion/trunk/subversion/bindings/swig/python: svn/ tests/
Date Sat, 17 Feb 2018 16:44:17 GMT
On Sat, Feb 17, 2018, 6:38 AM Stefan Sperling <> wrote:

> Hi Troy,
> The diff --normal option is a GNU extension and hence not portable to
> systems which do not use GNU diff.
> See
> which fails with:
> trunk/subversion/bindings/swig/python/tests/
> ............................................diff: unknown option -- normal
> I would suggest to just drop the --normal option if possible, because it
> seems to be the default behaviour for GNU diff and likely also other
> implementations.

Ah, well that is what I get for just looking at the help output on my box!
Honestly it is really cruft from my first cut at the test, where it took
having a non-empty list to actually call the executable  (versus the
current None check).

> Another suggestion: Is there a pythonic way to test for the existence
> of a 'diff' program, instead of assuming that any system except Windows
> has one installed?
> Our main test suite has a concept of 'skipped' tests, and if this exists
> in the python bindings tests as well it would make sense to report the
> test result as 'skipped' instead of 'pass' if no diff tool is available.

I did look at this for a bit since I hated the "not win32" check,
especially since you *could* have diff on windows. However,  it appeared
there was quite a bit of code to reimplement, and all the examples I found
still had something wrong with them for particular scenarios. But that
search was pretty windows-centric, and not particularly exhaustive.  It
seems it is worth another look. Surely there is a way to just try calling
it, and catch an exception or something similar without reimplementing
searching through the path and using platform-specific calling conventions
(like testing with and without .exe).

I'm research a better method for this and come up a solution that is a bit
more general.


View raw message