Hello, Padraig -

How are you?

Can you explain the behavior of diff(1) shown below?

With -U1 and -U2 , the --ignore-matching-lines='Id' argument suppresses
display of the difference between the 'Id' lines, as expected.

But with -U3, the diff of the 'Id' lines reappears,  in spite of the
--ignore-matching-lines='Id'
argument.

Why is that?

Thanks,
Todd Shandelman
Houston, Texas


############################################################

$ cat a
  #
  # ORIG: 2014-12-04 09:28:56 CST Thu
  #
  # $Id: a,v 1.8 2014/12/04 15:29:99 todd Exp todd $
  #
a
b
c
d
e

############################################################

$ cat b
  #
  # ORIG: 2014-12-04 09:28:56 CST Thu
  #
  # $Id: a,v 1.8 2014/12/04 15:29:27 todd Exp $
  #
a
c
D
e

############################################################

$ diff -v
diff (GNU diffutils) 2.8.1
Copyright (C) 2002 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

Written by Paul Eggert, Mike Haertel, David Hayes,
Richard Stallman, and Len Tower.

############################################################

$ diff -U1    a b
--- a 2014-12-08 16:07:05.974621828 -0600
+++ b 2014-12-08 16:07:09.693672957 -0600
@@ -3,8 +3,7 @@
   #
-  # $Id: a,v 1.8 2014/12/04 15:29:99 todd Exp todd $
+  # $Id: a,v 1.8 2014/12/04 15:29:27 todd Exp $
   #
 a
-b
 c
-d
+D
 e

############################################################


$ diff -U1   --ignore-matching-lines='Id'   a b
--- a 2014-12-08 16:07:05.974621828 -0600
+++ b 2014-12-08 16:07:09.693672957 -0600
@@ -6,5 +6,4 @@
 a
-b
 c
-d
+D
 e


############################################################


$ diff -U2   --ignore-matching-lines='Id'   a b
--- a 2014-12-08 16:07:05.974621828 -0600
+++ b 2014-12-08 16:07:09.693672957 -0600
@@ -5,6 +5,5 @@
   #
 a
-b
 c
-d
+D
 e

############################################################

$ diff -U3   --ignore-matching-lines='Id'   a b
--- a 2014-12-08 16:07:05.974621828 -0600
+++ b 2014-12-08 16:07:09.693672957 -0600
@@ -1,10 +1,9 @@
   #
   # ORIG: 2014-12-04 09:28:56 CST Thu
   #
-  # $Id: a,v 1.8 2014/12/04 15:29:99 todd Exp todd $
+  # $Id: a,v 1.8 2014/12/04 15:29:27 todd Exp $
   #
 a
-b
 c
-d
+D
 e

 ############################################################








On 9 December 2012 at 06:34, Pádraig Brady <P@draigbrady.com> wrote:

> On 12/07/2012 08:23 PM, Todd Shandelman wrote:
>
>> Hi,  bug-coreutils@gnu.org  -
>>
>> Not quite a bug, but why does the same option, essentially, have two very
>> different names in the 'expand' and 'unexpand'  utilities?
>>
>> This is confusing and hampers convenient usage.
>>
>> I am referring to* --initial* in the one case and* --first-only* in the
>> other.
>>
>> See below.
>>
>> Or what am I missing?
>>
>
> Yes that is inconsistent.
> Interestingly the POSIX defined expand and unexpand are inconsistent
> in relation to this to start with.
>
> unexpand only processes leading blanks by default, but
> expand processes all blanks by default.
>
> So unexpand needs the -a option to process all blanks,
> and expand needs the -i, --initial option to process only leading blanks.
>
> Given the above you might think that the --first-only option to unexpand
> is redundant.  However -a is implied by -t (as per POSIX), therefore
> to really limit to initial blanks, you need this option.
>
> So as for naming.  I agree that --first-only is inconsistent.
> It's also a bit ambiguous. Does it mean only the first tab is written,
> or all leading blanks are processed.  Now deprecating --first-only
> for the more consistent --initial has some cost.  For example
> it would break part of my FSlint program:
> http://code.google.com/p/fslint/source/browse/trunk/
> fslint/supprt/rmlint/fix_ws.sh
> Also, I see busybox copied --first-only into its unexpand implementation.
> But I guess to be forward looking --first-only should be deprecated
> in favor of --initial?
>
> thanks,
> Pádraig.
>