On Tuesday, 10.07.2012 at 15:57 +0000, Christoph Anton Mitterer wrote: > > I suggest a shell function instead of an alias, perhaps > > something like this: > I also thought about this at first (and writing one is obviously very > simple and a one liner...) > But > a) The advantage of an alias is, that it's surely never accidentally > used in non-interactive shells... which could easily happen with a > function, if non properly handled...
With an appropriately named function I don't see that as a problem: one
already has to be careful to correctly type commands in a variety of
contexts, of course.
Just as an example, I use:
function cvsdiff () { cvs diff $@ | colordiff; }
function gitdiff () { git diff $@ | colordiff; }
function bzrdiff () { bzr diff $@ | colordiff; }
If those functions are accidentally used elsewhere, nothing serious will
happen, e.g. "cvsdiff" instead of "cvs diff".
I agree that if you wish to use an alias/function which is named
identically to an existing binary, then problems may arise.
> b) It would sound reasonable to me in general, that when wdiff mode is
> specified as diff mode,... "colordiff a b" uses wdiff.
I understand your reason for suggesting this, as others have in the
past, but at this stage the "--diff-type" option is really just an
indicator to colordiff that the input which is being presented to it is
in a particular format (i.e. where diff type detection fails); it's not
an instruction to use a particular diff command or to feed diff
specified parameters.
Another point is that wdiff is less widely distributed than diff and so
may not be available, which adds a little more complexity were colordiff
required to check for that state.
> btw: One further question,... dies colordiff detect whether the output
> is connected to a terminal,... and only then (!!) modify the output (by
> color codes)?
colordiff does indeed do that, yes. The behaviour is on by default, but
colours can be forced by use of the color_patches option. This allows
one to do
colordiff oldcode.c newcode.c # shows colours
colordiff oldcode.c newcode.c > my.patch # no colours in patch
by recalling the previous command and adding '> my.patch' and have no
colours in the patch file.
> Ever thought about making patches for diff/wdiff themselves that add
> --color support?
Not really, beyond my skill to hack at that level! The purpose of
colordiff is (and has always been) to take existing diff-like output and
try to make sense of it for colour-highlighting purposes. :-)
Just to clarify the nature of this wishlist bug, are you suggesting that
the colordiff (Debian) package should be extended to provide an
additional command 'colorwdiff' in addition to the existing 'colordiff'
and 'cdiff', where colorwdiff utilises wdiff in the same way as
colordiff utilises diff? (Presumably this could be written as an
extension to colordiff.pl where it checks the command with which it was
invoked. There would also be the issue of a dependency on 'wdiff'.)
Dave.
--
Dave Ewart [email protected], http://twitter.com/DaveEwart
All email from me is digitally signed, http://www.sungate.co.uk/
Fingerprint: AEC5 9360 0A35 7F66 66E9 82E4 9E10 6769 CD28 DA92
signature.asc
Description: Digital signature
