GNU bug report logs - #20120
wc output padding differs when "-" is in the file list

Previous Next

Package: coreutils;

Reported by: Eric Mrak <mail <at> ericmrak.info>

Date: Mon, 16 Mar 2015 16:23:02 UTC

Severity: normal

Tags: wontfix

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

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20120 in the body.
You can then email your comments to 20120 AT debbugs.gnu.org in the normal way.

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#20120; Package coreutils. (Mon, 16 Mar 2015 16:23:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Eric Mrak <mail <at> ericmrak.info>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Mon, 16 Mar 2015 16:23:02 GMT) Full text and rfc822 format available.

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

From: Eric Mrak <mail <at> ericmrak.info>
To: bug-coreutils <at> gnu.org
Subject: wc output padding differs when "-" is in the file list
Date: Sun, 15 Mar 2015 22:42:59 -0700
[Message part 1 (text/plain, inline)]
It seems that whenever STDIN is involved the results padding reverts to the
BSD-style 7/8 padding. When files are given as input (excluding STDIN) the
padding reflects the width of the largest count. When files are given as
input and one of these is "-", the padding reverts again to the BSD 7/8
padding.

System: Arch Linux (package: core/coreutils 8.23-1)

===================
$ wc --version
wc (GNU coreutils) 8.23
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Paul Rubin and David MacKenzie.
===================

Actual:

===================
$ echo "some text" > test.txt
$ printf %s "one\ntwo\nthree" | wc - test.txt
      3       3      14 -
      1       2      10 test.txt
      4       5      24 total
===================

Expected:

===============
$ echo "some text" > test.txt
$ printf %s "one\ntwo\nthree" | wc - test.txt
 3  3 14 -
 1  2 10 test.txt
 4  5 24 total
===================
[Message part 2 (text/html, inline)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#20120; Package coreutils. (Thu, 19 Mar 2015 09:21:02 GMT) Full text and rfc822 format available.

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Eric Mrak <mail <at> ericmrak.info>, 20120 <at> debbugs.gnu.org
Subject: Re: bug#20120: wc output padding differs when "-" is in the file list
Date: Wed, 18 Mar 2015 18:54:05 +0100
On 03/16/2015 06:42 AM, Eric Mrak wrote:
> It seems that whenever STDIN is involved the results padding
> reverts to the BSD-style 7/8 padding. When files are given
> as input (excluding STDIN) the padding reflects the width of
> the largest count.
> When files are given as input and one of these is "-", the
> padding reverts again to the BSD 7/8 padding.

Thanks for the report.
This effect is there at least since the last bigger change in
this area, the introduction of the function compute_number_width(),
back in 2003.

Furthermore, strange formatting also happend in other cases,
e.g. for other non-regular files ...

  $ wc /etc/hosts /dev/null
       41     124    1355 /etc/hosts
        0       0       0 /dev/null
       41     124    1355 total

... or where stat() returns a wrong value like for /proc files ...

  $ wc /proc/cpuinfo x
  52 256 1276 /proc/cpuinfo
  1 0 1 x
  53 256 1277 total

... or with the --files0-from=FILE option:

  $ printf '%s\0' x /etc/hosts | wc --files0=-
  1 0 1 x
  41 124 1355 /etc/hosts
  42 124 1356 total

The number width is determined before reading the actual files.
I'm asking myself if it would hurt to save the values for all files
until all of them are read, and then do the calculation of the
number width and the printing of all values.
OTOH this would delay output until all files are read (besides
the memory footprint).
Any opinions if a proper output format warrants this disadvantages?

Regarding the number width fallback of %7d: this is mentioned in
the POSIX specification (in 'Rationale'), but I'm unsure if it's
mandated/ recommended/deprecated behavior.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/wc.html

Have a nice day,
Berny




Information forwarded to bug-coreutils <at> gnu.org:
bug#20120; Package coreutils. (Thu, 19 Mar 2015 10:39:02 GMT) Full text and rfc822 format available.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>, 
 Eric Mrak <mail <at> ericmrak.info>, 20120 <at> debbugs.gnu.org
Subject: Re: bug#20120: wc output padding differs when "-" is in the file list
Date: Thu, 19 Mar 2015 10:38:11 +0000
On 18/03/15 17:54, Bernhard Voelker wrote:
> On 03/16/2015 06:42 AM, Eric Mrak wrote:
>> It seems that whenever STDIN is involved the results padding
>> reverts to the BSD-style 7/8 padding. When files are given
>> as input (excluding STDIN) the padding reflects the width of
>> the largest count.
>> When files are given as input and one of these is "-", the
>> padding reverts again to the BSD 7/8 padding.
> 
> Thanks for the report.
> This effect is there at least since the last bigger change in
> this area, the introduction of the function compute_number_width(),
> back in 2003.
> 
> Furthermore, strange formatting also happend in other cases,
> e.g. for other non-regular files ...
> 
>    $ wc /etc/hosts /dev/null
>         41     124    1355 /etc/hosts
>          0       0       0 /dev/null
>         41     124    1355 total
> 
> ... or where stat() returns a wrong value like for /proc files ...
> 
>    $ wc /proc/cpuinfo x
>    52 256 1276 /proc/cpuinfo
>    1 0 1 x
>    53 256 1277 total
> 
> ... or with the --files0-from=FILE option:
> 
>    $ printf '%s\0' x /etc/hosts | wc --files0=-
>    1 0 1 x
>    41 124 1355 /etc/hosts
>    42 124 1356 total
> 
> The number width is determined before reading the actual files.
> I'm asking myself if it would hurt to save the values for all files
> until all of them are read, and then do the calculation of the
> number width and the printing of all values.
> OTOH this would delay output until all files are read (besides
> the memory footprint).
> Any opinions if a proper output format warrants this disadvantages?

Changing to unbounded memory (albeit slowly increasing) is not worth it I think.

> Regarding the number width fallback of %7d: this is mentioned in
> the POSIX specification (in 'Rationale'), but I'm unsure if it's
> mandated/ recommended/deprecated behavior.
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/wc.html

The existing padding is only a nicety.
If I was going to change anything, I'd add field selection and left/right
alignment support to column(1).

cheers,
Pádraig.




Information forwarded to bug-coreutils <at> gnu.org:
bug#20120; Package coreutils. (Tue, 23 Oct 2018 02:02:02 GMT) Full text and rfc822 format available.

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

From: Assaf Gordon <assafgordon <at> gmail.com>
To: 20120 <at> debbugs.gnu.org
Subject: Re: bug#20120: wc output padding differs when "-" is in the file list
Date: Mon, 22 Oct 2018 20:01:07 -0600
tags 20120 wontfix
close 20120
stop

(triaging old bugs)

On 19/03/15 04:38 AM, Pádraig Brady wrote:
> On 18/03/15 17:54, Bernhard Voelker wrote:
>> On 03/16/2015 06:42 AM, Eric Mrak wrote:
>>> It seems that whenever STDIN is involved the results padding
>>> reverts to the BSD-style 7/8 padding. 
>>
>> Thanks for the report.
>> This effect is there at least since the last bigger change in
>> this area, the introduction of the function compute_number_width(),
>> back in 2003.
>
> The existing padding is only a nicety.
> If I was going to change anything, I'd add field selection and left/right
> alignment support to column(1).

Given the above, and without further comments in 3 years,
I'm closing this bug.

Discussion can continue by replying to this thread.

-assaf




Added tag(s) wontfix. Request was from Assaf Gordon <assafgordon <at> gmail.com> to control <at> debbugs.gnu.org. (Tue, 23 Oct 2018 02:02:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 20120 <at> debbugs.gnu.org and Eric Mrak <mail <at> ericmrak.info> Request was from Assaf Gordon <assafgordon <at> gmail.com> to control <at> debbugs.gnu.org. (Tue, 23 Oct 2018 02:02:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 20 Nov 2018 12:24:05 GMT) Full text and rfc822 format available.

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.