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

[Norbert Kiesel]

Yeah, I got that POSIXLY_CORRECT idea backwards: I wanted to suggest to keep the default as --normal when POSIXLY_CORRECT is set, and otherwise switch to --unified.

I also understand the reluctance to add another environment variable that changes behavior.

But: --normal is _really_ no longer what user normally want or use.  I would even go so far to say that it's never used anymore. Yes, there might be the one-off script that really expects the diff --normal output.  But that most likely runs on a Solaris system that was not updated since 1995 and thus anyway will never encounter this change.

On Thu, Oct 6, 2016 at 1:18 PM, Eric Blake <address@hidden> wrote:

tag 24629 notabug
thanks

On 10/06/2016 02:48 PM, Norbert Kiesel wrote:
> Hi,
>
> it's been ages that I actually wanted to produce a "classic" diff, and
> I don't think I'm alone in that.  Yet, I still have to remember to add
> `-u` every time I invoke `diff`.
>
> I understand changing the default is controversial. But perhaps even
> using "classic" as default unless POSIXLY_CORRECT is set.

I think you said that backwards, and are proposing that diff would
output -u format by default, and ed script format if POSIXLY_CORRECT is
set.  At any rate, I'm not a big fan of the idea; POSIXLY_CORRECT should
control an absolute bare minimum of changes (only where we intentionally
differ from POSIX as in incompatible extension), as you still risk
breaking many scripts (most of which intentionally don't sent
POSIXLY_CORRECT).

>
> But we should be able to support a GNU_DIFF_FORMAT environment
> variable that sets the default format, no?

No. We've already learned, from sad experience, that environment
variables that affect default behavior are VERY prone to breaking
existing scripts that aren't aware of the new environment variable
needing to be removed before getting the output they are used to.  In
fact, existing GNU programs have been actively trying to move away from
this paradigm (observe the treatment of GREP_OPTIONS in grep).
Environment variables that affect non-default output, such as LS_COLORS,
are less problematic - except that then they aren't the default so it
still doesn't help your stated use case of getting the new behavior by
default.

>
> I could send a patch, but first want to understand if that would have
> any chance of being applied.

Probably not worth it.  As such, I'm tagging this as not a bug in the
database, although you should feel free to add further comments to the
thread.

>
> </nk>
>
> P.S.: I know I could write my own little wrapper script/alias/shell
> function, but that all seems dirty in one way or another. --nk

Actually, that IS what we recommend.  If you have a particular way that
a tool behaves best for you, then the BEST thing to do IS to write a
wrapper script which adds the appropriate options, and put that wrapper
script first on your PATH for interactive operation.

--
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org