<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 15, 2024 at 2:06 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/15/24 09:58, enh wrote:<br>
> On Thu, Mar 14, 2024 at 9:25 PM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>> wrote:<br>
> > I could make ours do that, or I could export NOSPACE=1 at the start o the test<br>
> > (since each one runs as a child process now meaning environment variable<br>
> > assignments won't persist into other tests)<br>
> <br>
> or have a NOSPACE that _doesn't_ reset?<br>
<br>
NOSPACE already doesn't reset, I've been doing shell prefix assignment to set it<br>
for individual commands, ala:<br>
<br>
$ NOSPACE=1 bash -c 'env | grep NOSPACE'<br>
NOSPACE=1<br>
$ echo -n $NOSPACE<br>
$<br>
<br>
If I just NOSPACE=1 on its own line it should apply to all the tests in the<br>
current script, then clean up at the end because each test script runs as a<br>
(child process) with its own environment.<br>
<br>
And that's probably correct here because diff -b ignores changes in the AMOUNT<br>
of space but not the EXISTENCE of space, so "a b c" and "abc" still wouldn't<br>
match, which is what I was worried about. (I thought -b yanks space, but instead<br>
it normalizes it.)<br>
<br>
> i feel like most of the tools that<br>
> produce human-readable output have this problem otherwise: (a) upstream often<br>
> has a weird duplicative implementation that leads to bizarre behavior and (b)<br>
> they keep changing things (possibly without even noticing, since it's whitespace).<br>
<br>
Sure, but that said some tests _DO_ care about the exact amount of whitespace<br>
(are columns aligned), or tabs vs spaces.<br></blockquote><div><br></div><div>i know what you mean, but at the same time, i'm struggling to thing of a single case i've been involved with where the "upstream" tool hasn't screwed me over by doing something stupid sooner or later...</div><div><br></div><div>CANONICALIZE_SPACE_IF_RUNNING_HOST_VERSION=1? so we trust ourselves but no-one else? :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> (xxd, which has the `-r` option, seems like the partial exception, but even<br>
> there as long as xxd can consume any [text] input it's likely to be given, i<br>
> don't think it matters exactly what the text output's whitespace looks like?)<br>
> <br>
> <br>
> but that weakens the test, or maybe<br>
> I could add a "NOTRAIL=1" that runs the output through sed 's/[ \t]*$//' or some<br>
> such?<br>
> <br>
> Anyway, reviewing commands to promote them out of pending is a thing, and I'm<br>
> trying close tabs rather than open more just now.<br>
> <br>
> (i didn't even realize there was a hexdump in pending! missed that somehow...)<br>
<br>
It mostly comes up when I complain we've got FOUR hex dumpers that share no code<br>
(it's the fourth, you added the third with xxd, posix od and my hexedit were the<br>
first two), but the recent revisit tipped me over into "alright, I'll clean it<br>
up..."<br>
<br>
The problem is "dump hex" isn't a big enough job that pulling it out into a<br>
library function that can be shared is really a win. It's another one of those<br>
"the fighting is so vicious because the stakes are so small" things. Maybe if I<br>
could genericize the "show hex in 4 digit groups, now do octal!" variants into<br>
some sort of engine... but I worry that the glue to call the engine would be<br>
bigger than any savings.<br></blockquote><div><br></div><div>od and hexdump are weird there in that the former lets you express quite a large variety of different dumps, and the latter (i think) pretty much anything. i have wondered whether the others can't mostly be written in terms of hexdump. (xxd still has all the reverse stuff, but as long as no-one else does, that's not duplication.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
*shrug* Punt that for a potential post-1.0 cleanup pass, and lump it in the<br>
meantime...<br></blockquote><div><br></div><div>yeah, like you say, these are some of the simplest commands anyway. i'd be a lot more worried if we had four seds or four shells :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Rob<br>
> <br>
> P.S. In THEORY the chmod +x bit on tests/*.test is the equivalent of "pending",<br>
> where "make tests" only runs the ones marked executable but you can still run<br>
> them individually/standalone with "make test_commandname". In practice, the<br>
> pending status of commands and the pending status of TESTS isn't a 1-1 match up.<br>
<br>
Yes I saw your email in the other thread about pending not being granular<br>
enough, but didn't really have anything coherent to say in response? I see<br>
pending as an unfinished todo heap I need to drain, and I feel bad for not<br>
cleaning it up fast enough. Doing non-cleaning work there is like organizing<br>
trash piles. Attempting to categorize the bulk wasn't an unambiguous win even<br>
for toys/ which is _intended_ to keep growing rather than shrink, so adding it<br>
to pending doesn't appeal. I don't really want spend architectural design cycles<br>
on scaffolding that gets torn down again.<br></blockquote><div><br></div><div>indeed.</div><div><br></div><div>i think the only half-way practical idea i had was "keep pending but just switch to a much scarier name". because, to be fair to the confused, in english "pending" _can_ legitimately mean "almost there". whereas your whole point with pending is "i actually have _no_ idea how close this is yet". if i _had_ to do something today, renaming "pending" to "experimental" is probably where i'd land. but then this would look rather suspect over in the aosp build system:</div><div><br></div><div> "toys/pending/diff.c",<br> "toys/pending/expr.c",<br> "toys/pending/tr.c",<br></div><div>...</div><div> "toys/pending/brctl.c",<br> "toys/pending/getfattr.c",<br> "toys/pending/lsof.c",<br> "toys/pending/modprobe.c",<br> "toys/pending/more.c",<br> "toys/pending/stty.c",<br> "toys/pending/traceroute.c",<br> "toys/pending/vi.c",<br></div><div><br></div><div>:-)</div><div><br></div><div>oh, btw, i realized next time i tried why i've struggled to make myself do `toys/*/foo.c` ... it's because the shell won't tab-expand through the `/*/` even if only one directory matches, and i tab complete all the time :-(</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rob<br>
</blockquote></div></div>