[Toybox] [PATCH] Make ls.test work without awk.

[Rob Landley]

On 04/11/2017 02:56 PM, enh wrote:
>     Also, I want a grep option that ignores whitespace differences like
>     patch -l does. Squash all runs of whitespace to one ascii 32 space
>     character, then compare. Alas I'd probably have to use a --longopt for
>     the name and I dislike those slightly more than I want this feature.
> 
> 
> speaking of which: all the blkid tests fail if you run it on the desktop
> because you don't output trailing spaces.

Because trailing spaces are usually bad. :)

And my ls -C has one space between columns as its minimal packing, when
ubuntu has two. (Do a "ls toys" in the toybox source, for example. The
default is -C.) That was a judgement call but if -m can do one space and
consider it legible why can't -C?

> i'm not sure whether to
> "break" toybox blkid to just always output trailing spaces or make the
> test less readable to allow either output. (regular expression matches
> rather than just literal matches might help here.)

Hence grep ignoring whitespace. :P

Invoking my "black belt in horrible solutions", I could make a sgrep
shell function that modifies grep's first argument to replace each " "
with "[:space:][:space:]*" and then add a "[:space:]*" to the beginning
and the end...

This fixes it for the test code but not as a generally available thing.
(I still have to redo adding grep color support. It turns out to be
intrusive because it's a second user of the -o logic which is currently
specific to -o...)

Not sure which approach to take...

>     (You want to know why I can't work through my todo list until it's
>     smaller? That's why. Working through my todo list makes it BIGGER.
>     Always has.)
> 
> everyone else's too. this is why we give in and have bug databases.
> anr/or XFAIL tests.

No, I've met people who go through a todo list and reach the end without
new todo items. Not sure if this is "boring projects", "boring people",
or some sort of skill I haven't got.

>     Except... looking in ls there's code to do this. Why isn't it
>     triggering... Huh, Izabera pointed out that ubuntu's ls defaults to -q
>     and so I made it do that, and -q trumps -b. Blah.
> 
>     Ok, fixed and my code is escaping \e which ubuntu's ls isn't. But both
>     printf and echo support \e so I think I'm right. :)

I changed the default output (when there's a tty) to -b rather than -q,
so it's accurately escaping stuff instead of wildcarding it out. This
differs from upstream ls but I think is better behavior. I can change it
back if it breaks stuff for you.

Rob