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.
