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 <ebl...@redhat.com> 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 > >
