[bug-diffutils] bug#20062: bug#20062: bug#20062: bug#20062: bug#20062: bug#20062: bug#20062: bug#20062: [PATCH] diff: add support for --color

[Aaron Davies]

On Oct 20, 2015, at 12:42 PM, Eric Blake <address@hidden> wrote:

>> On 10/20/2015 10:25 AM, Paul Eggert wrote:
>> Giuseppe Scrivano wrote:
>>> diff honors DIFF_COLORS
>>> now.
>> 
>> Aren't we trying to move away from environment variables' affecting
>> program behavior, given all the maintenance and security hassles that
>> entails?
> 
> I think there's a difference between an environment variable which only
> affects optional behavior (LS_COLORS, DIFF_COLORS - only affect things
> for 'ls --color' or 'diff --color') vs. those that affect ALL behavior
> (GREP_OPTIONS - cruelly affects all executions of grep, no matter what
> options were in use).
> 
> You do have a point that allowing the choice to come through a command
> line option, and wrapping diff behind an alias or shell function, will
> let the interactive user set up their terminal to get the same effect
> (typing 'diff' gets the colored version, whether the details were hidden
> behind an env-var or a shell alias).
> 
> Other arguments:
> In favor of an env-var:
> LS_COLORS is now understood by more than just 'ls' - at least tcsh
> honors the contents of LS_COLORS (sometimes good, but also annoying when
> we extend 'ls' to understand new options and then tcsh spews out error
> messages about unknown directives in LS_COLORS).
> Likewise, other programs could be taught to honor DIFF_COLORS (git,
> perhaps?) - but do we then need a common location to specify how it
> works so that all future programs buy in to the same interpretation?
> 
> Against env-var:
> LS_COLORS is already quite large, and we may be adding yet another large
> env-var in DIFF_COLORS. On some platforms, the environment space is
> already limited; on mingw, every byte added in the environment is one
> less byte towards the command line maximum limit (argv and env share the
> same 64k block of memory - not quite POSIX-y, but not all the world is
> POSIX).
> In an interactive environment, the user is already likely to be creating
> a shell alias/function to turn 'diff' into 'diff --color' - it is not
> that much harder to have the alias be 'diff --color
> --option-to-set-colors' compared to 'DIFF_COLORS=... diff --color', but
> conceptually having it all through the command line rather than split
> among two sources makes it easier to trace where the change is made.
> 
> I don't have a strong opinion on whether an env-var is right or wrong,
> so long as we have at least SOME way to override default colors.  But I
> _do_ think that this is at least a safe env-var if we want to go that
> route (since it only affects the behavior of opt-in --color usage,
> rather than all situations).

I'm very new here, so feel free to take my opinions with a grain of salt, but 
one thing I've been noticing in my scripting work is that environment 
variables' biggest drawback is often also their big advantage: you don't have 
to propagate them manually.

Suppose you want to encapsulate some common diff operation in a small shell 
script. Then anything you want that diff to do that you specified in an alias 
or function in your interactive shell has to be written out again.

Alternatively, you could have a diff wrapper in your ~/bin setting the option, 
but it's hard to actually write those correctly to handle things like stdin vs. 
file args.

None of this comes with env vars.

Still, I understand your other concerns.

Maybe a ~/.diffrc is the solution?