GNU bug report logs - #19319
? Unexpected behavior in diff(1)

Previous Next

Package: coreutils;

Reported by: Todd Shandelman <todd.shandelman <at> gmail.com>

Date: Mon, 8 Dec 2014 22:29:01 UTC

Severity: normal

Tags: notabug

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Todd Shandelman <todd.shandelman <at> gmail.com>
To: P <at> draigbrady.com, 19319 <at> debbugs.gnu.org
Subject: bug#19319: ? Unexpected behavior in diff(1)
Date: Mon, 8 Dec 2014 16:27:52 -0600
[Message part 1 (text/plain, inline)]
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 <at> draigbrady.com> wrote:

> On 12/07/2012 08:23 PM, Todd Shandelman wrote:
>
>> Hi,  bug-coreutils <at> 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.
>
[Message part 2 (text/html, inline)]

This bug report was last modified 6 years and 216 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.