On 01/22/2018 04:08 PM, enh wrote: > Switch the printf over to %s because the input is actually hex (so %d > is wrong), but without the leading "0x" that %x would require. > > For some reason the NODE assignment wasn't providing any input to awk > (hence the hang),
Because I was going to save the stat output in an environment variable and then parse the two fields out of that rather than calling stat twice (more or less out of habit from "fetching data fro the same file twice? Race condition, it could change between!")... > and awk wasn't looking for the correct field anyway. > > The tests still fail for me: > > losetup: /dev/block/loop0: No such device or address > losetup: /dev/block/loop0: No such device or address > losetup: file: No such file or directory > losetup: needs 1 arg (see "losetup --help") > > But at least now they allow the other tests to continue! I really, really, really need tests/pending. I have no idea why that file is checked in. (Probably I was thinking of some other command's tests.) It's basically a couple notes to self for when I actually implement these tests. I need to do losetup tests but it's in the "needs root" bucket which means "needs qemu" which means "needs mkroot"... This isn't even a hard one (ala bind mounting stuff over /proc to get reproducible ps tests, or the "ptywrap" thing I need to write to test the screen width queries in ls and ps and such). It just needs the basic "run this test as root with known kernel config in a freshly rebooted system (so nobody's already _using_ any of the loop devices and we get consistent numbers) which we can shut down afterwards so tests that fail in a way that prevents us from cleaning up after them doesn't make me reboot my netbook to get back to a known state..." (Ok, yeah, thats a long stretch of quote marks.) Lemme see if I can find some time to shovel this out too... Rob P.S. All root tests are a _bit_ funky because I also wanna make TEST_HOST pass for them, and getting non-toybox implementations similarly wrappered? Probably debootstrap and package it into an ext3 root filesystem I can plug into the same kernel under qemu. It's on the todo list. No a container isn't quite good enough if for example the tests needs to ensure the equivalent of "insmod dummy" is available. Not unless I tailor the tests to expect a specific version of a specific distro, which is bit-rot waiting to happen... P.P.S. what I REALLY need it some way to force ps or top to deal with processes exiting while it's examining them. But even if I did something truly horrible with ptrace or perhaps a fuse filesystem providing a fake ps, it would only test certain specific "file goes away between this operation and that operation", which are the kind of specific things I'd already have fixed if I noticed them and knew to test for them. Alas, fuzzing seems the only way to really get good coverage there, and this is really a regression test suite built around deterministic behavior. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
