<div dir="auto">(note that the test changes also fix HOST=1 which was previously failing those test cases.)</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 6, 2018, 13:03 enh <<a href="mailto:enh@google.com">enh@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">TL;DR: patch attached<br>
<br>
(background: i've been trying to use toybox on my desktop too.)<br>
<br>
i was surprised to see that toybox `wc -l` doesn't columnate:<br>
<br>
$ ./toybox wc -l [Mm]*<br>
256 main.c<br>
69 Makefile<br>
325 total<br>
<br>
here's what i was expecting to see.<br>
<br>
$ wc -l [Mm]*<br>
 256 main.c<br>
  69 Makefile<br>
 325 total<br>
<br>
i thought i'd send a patch, but:<br>
<br>
(a) "don't columnate unless more than one flag is set" seems<br>
deliberate, but i don't understand why:<br>
<br>
   for (i = 0; i<4; i++) if (toys.optflags == (1<<i)) space = 0;<br>
<br>
(b) POSIX does say _nothing_ should be columnated:<br>
<br>
  By default, the standard output shall contain an entry for each<br>
input file of the form:<br>
<br>
  "%d %d %d %s\n", <newlines>, <words>, <bytes>, <file><br>
<br>
  ...<br>
<br>
  The output file format pseudo- printf() string differs from the<br>
System V version of wc:<br>
<br>
  "%7d%7d%7d %s\n"<br>
<br>
  which produces possibly ambiguous and unparsable results for very<br>
large files, as it assumes no number shall exceed six digits.<br>
<br>
ah, i think i see what you were trying to say... you wanted this:<br>
<br>
$ cat /proc/version | wc -l -<br>
1 -<br>
$ cat /proc/version | wc -l<br>
1<br>
<br>
and `info wc` says<br>
<br>
  However, as a GNU extension, if only one count is printed, it is<br>
  guaranteed to be printed without leading spaces.<br>
<br>
hmm. except i can't explain this:<br>
<br>
$ wc -l /etc/csh.*<br>
 18 /etc/csh.cshrc<br>
 11 /etc/csh.login<br>
  1 /etc/csh.logout<br>
 30 total<br>
$ wc -l /proc/[c]*<br>
12 /proc/cgroups<br>
1 /proc/cmdline<br>
1 /proc/consoles<br>
1296 /proc/cpuinfo<br>
458 /proc/crypto<br>
1768 total<br>
<br>
i can't explain (a) why the first example uses a column width of 3,<br>
nor (b) why the second example doesn't columnate. presumably it's<br>
something to do with those files claiming size 0, though i've no idea<br>
how/why it's deciding how big to make the *lines* column from the file<br>
size. oh, yeah, it can assume that every character in the file is a<br>
newline, and thus get an upper bound on the number of lines.<br>
<br>
okay, so i'm guessing the GNU heuristic is something like a two-pass<br>
"stat all the files first, and use the max byte count as the the<br>
column width", and /proc actually isn't a special case in their code:<br>
it's a bug because their heuristic is broken for files that read<br>
larger than they claim to be.<br>
<br>
so, anyway... it looks like you've implemented the documented GNU<br>
extension, but in practice they don't actually do what they claim to<br>
do. it seems like the true GNU extension is actually "there are no<br>
leading spaces if only one count is printed *and* there's only one<br>
file".<br>
<br>
ah, i think we've just misinterpreted what "only one count" means in<br>
the GNU doc: they mean one *file*, not one *column*. that certainly<br>
seems to match the actual behavior.<br>
<br>
fix attached.<br>
</blockquote></div>