<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 14, 2024 at 9:25 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">Following up on commit cab0b6653827, the hexdump test suite is weird. For<br>
example, the first test has "simple\\n" when it means "simple\n" (which<br>
nevertheless somehow works for reasons I am loathe to examine at the moment, and<br>
I have a todo item to convert the various test arguments needing escapes to<br>
$'blah\n' arguments where the shell does it instead of washing it through echo<br>
inside the function, but that is a giant flag day change for some point where<br>
I'm facing a clean tree.)<br>
<br>
But the bigger problem is that TEST_HOST doesn't pass because debian's hexdump<br>
is doing something silly:<br>
<br>
  $ echo -e 'simple\n' | hexdump | sed 's/$/./'<br>
  0000000 6973 706d 656c 0a0a                    .<br>
  0000008.<br>
<br>
I.E. padding short lines with trailing spaces, because of course.<br>
<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)</blockquote><div><br></div><div>or have a NOSPACE that _doesn't_ reset? i feel like most of the tools that produce human-readable output have this problem otherwise: (a) upstream often has a weird duplicative implementation that leads to bizarre behavior and (b) they keep changing things (possibly without even noticing, since it's whitespace).</div><div><br></div><div>(xxd, which has the `-r` option, seems like the partial exception, but even there as long as xxd can consume any [text] input it's likely to be given, i don't think it matters exactly what the text output's whitespace looks like?)</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"> 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></blockquote><div><br></div><div>(i didn't even realize there was a hexdump in pending! missed that somehow...)</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>
Toybox mailing list<br>
<a href="mailto:Toybox@lists.landley.net" target="_blank">Toybox@lists.landley.net</a><br>
<a href="http://lists.landley.net/listinfo.cgi/toybox-landley.net" rel="noreferrer" target="_blank">http://lists.landley.net/listinfo.cgi/toybox-landley.net</a><br>
</blockquote></div></div>