Re: uniq -c outputs SPACES NUMBER TAB LINE

[Leif LeBaron]

> Would you care to submit a documentation patch?

... 


I have much respect and appreciation for rms & al. whose work has contributed 
to 
software/information freedom; however, I am increasingly dismayed with 
GNU software, and increasingly diverted to other tools.

It seems useful to promote the potential of potent simplicity.

http://harmful.cat-v.org/cat-v/unix_prog_design.pdf



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: uniq -c outputs SPACES NUMBER TAB LINE

[Eric Blake]

Leif LeBaron  bb9.org> writes:

Hello Leif,

> 
> > Why do you think it's a bug?
> 
> I imagine the insertion of leading spaces was deliberate, but I refer to it 
as bug because it has already been
> registered as such in your bug tracker, and also for the following reasons.
> 
> - It appears to be undocumented (I checked both, man and info pages).

Would you care to submit a documentation patch?

> 
> - It appears to violate susv3
> () which 
clearly states:

That link is outdated (from POSIX 2001); the latest text (from POSIX 2008) is 
here:

http://www.opengroup.org/onlinepubs/9699919799/utilities/uniq.html

But the text you quoted is still the same across the two releases:

> 
>   If the -c option is specified, the output file shall be empty or each 
line shall be of the form:
>   "%d %s", , 

The thing you are missing, however, are these additional lines from POSIX 
(again, I'm quoting POSIX 2008, but identical wording was in POSIX 2001):

http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap05.html#tag_05

| ' ' 
| (An empty character position.) Represents one or more  characters.
...
| If both the field width and precision are omitted, the implementation may
| precede, follow, or precede and follow numeric arguments of types d , i , and
| u with  characters

And since both  and  fall in the category of , and the %d 
specifies neither width nor precision, our existing output with leading spaces 
and a separating tab is 100% compliant.

> 
> - It breaks other commands, for example:
> 
>   This should work:
>   
>   cat textfile | sort | uniq -c | cut -d " " -f 2-

No, POSIX does not guarantee that it will work.

> > Please reply not to me directly, but rather to the
> > bug-coreutils  gnu.org mailing list.
> 
> By the way, I replied using the button on the website
>  (so, 
you may want to
> change that address).

The bug-textutils list is old, from the days before it was consolidated to bug-
coreutils.  But the old alias still forwards to the new list.

-- 
Eric Blake





___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: uniq -c outputs SPACES NUMBER TAB LINE

[Leif LeBaron]

> Why do you think it's a bug?

I imagine the insertion of leading spaces was deliberate, but I refer to it as 
bug because it has already been registered as such in your bug tracker, and 
also for the following reasons.

- It appears to be undocumented (I checked both, man and info pages).

- It appears to violate susv3 
() which 
clearly states:

If the -c option is specified, the output file shall be empty or each 
line shall be of the form:
"%d %s", , 

- It breaks other commands, for example:

This should work:

cat textfile | sort | uniq -c | cut -d " " -f 2-

But instead the leading spaces must first be removed:

cat textfile | sort | uniq -c | sed 's/^[ \t]*//' | cut -d " " 
-f 2-


> Please reply not to me directly, but rather to the
> bug-coreutils@gnu.org mailing list.

By the way, I replied using the button on the website 
 (so, 
you may want to change that address).

Please confirm that this message has been received.

Thanks,
Leif


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils