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 <egg...@cs.ucla.edu> 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.... >
