GNU bug report logs - #20287
doc: improve comm,uniq manuals

Previous Next

To reply to this bug, email your comments to 20287 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: anti plex <antiplex <at> coma.cc>
To: bug-coreutils <at> gnu.org
Subject: comm does not imply uniq
Date: Thu, 9 Apr 2015 19:21:54 +0200

[Message part 1 (text/plain, inline)]

Hi there,

This is not meant to be a bug in the classic sense but rather a minor
suggestion for a manpage-improvement.

Albeit being a Linux-user for some years I've just re-discovered comm to
compare two files with md5-hashes. Some entries (lines) in one file
occurred twice wile being present zero or one time in the other file which
lead to weird results in combination with e.g. '-23' as i expected the
output to be exclusive to file1.
The repetitive use of the word 'unique' in the manpage ('Column one
contains lines unique to FILE1, column two contains lines unique to FILE2,
and column three contains lines common to both files.') further lured me to
think in this direction.

Thinking further about the behaviour of comm in the light of "Compare
sorted files FILE1 and FILE2 line by line." being mentioned in the manpage
one could induce that duplicate lines will be seen as differences of
course. Still, some additional hint just like mentioning that comm expects
each file to be sorted would have helped me to avoid some headaches ;)

Therefore I'd like to suggest to add a short hint such as 'Note that comm
does not imply checking for repetitive lines in either file so consider
some form of uniq-ification if expecting entries in each output-column to
be exclusive'.

Thanks for providing such a wonderful toolset,
regards, antiplex

[Message part 2 (text/html, inline)]

Previous Next

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