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).

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