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

Previous Next

Full log

View this message in rfc822 format

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: 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.

Previous Next

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