bug#20120: wc output padding differs when "-" is in the file list
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
bug#20120: wc output padding differs when - is in the file list
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 1241355 /etc/hosts 0 0 0 /dev/null 41 1241355 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.
bug#20120: wc output padding differs when - is in the file list
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 1241355 /etc/hosts 0 0 0 /dev/null 41 1241355 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
bug#20120: wc output padding differs when - is in the file list
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 ===
