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