[bug-diffutils] bug#24629: bug#24629: Make unified diff configurable default

[Norbert Kiesel]

Nope, keep it coming!

All valid concerns. I will think about it a bit more and come back with a revised patch.

One idea for your second point could be that only --normal can be overwritten by later style options.

Your example is also showing why Eric's idea of a wrapper script is not that simple: I sometimes do use `diff -U0`, and thus his recommended `exec diff --unified "$@"` would suffer from the same problems.

Perhaps adding a new `--default-style` option which is only used when no other style is specified is also an option.  That way, I could have my local diff run `exec /usr/bin/diff --default-style=unified "$@"`.  And still better than an environment variable.  One slight problem is the funky way that --default-style=unified=7 would look like. And of course that this has to be parsed again.  So perhaps we could get aways with only supporting normal, unified, and context as values for default-style.

On Thu, Oct 6, 2016 at 4:48 PM, Paul Eggert <address@hidden> wrote:

I'm afraid it's not that simple. The patch will cause diff3 to output that warning, since diff3 uses diff without --normal, so diff3.c needs fixing. Also, the manual needs fixing (doc/diffutils.texi). And the output of "diff --help" (src/diff.c). And there should be a test case testing the new behavior.

More important. Suppose I want a program with GNU diff's traditional behavior and so use a shell script 'mydiff' like this:

  #!/bin/sh
  exec diff --normal "$@"

This won't work, because if I invoke the script like this:

  mydiff -c foo bar

diff will complain about --normal conflicting with -c. So I suppose diff needs to change so that later output specifiers override earlier. But here things are a bit tricky, e.g., right now '-C5 -c' is equivalent to '-c -C5' and I assume we don't want to change this.

One other idea. If the invoker uses any long option, or any option other than -b and -r, diff can default to the -u output format regardless of whether POSIXLY_CORRECT is set. This is because POSIX does not specify the behavior of these other options.

Plus, it would be nice if we could address Eric's concerns somehow.

I hope I haven't scared you away entirely....