On Fri, Mar 15, 2024 at 2:06 PM Rob Landley <r...@landley.net> wrote:
> On 3/15/24 09:58, enh wrote: > > On Thu, Mar 14, 2024 at 9:25 PM Rob Landley <r...@landley.net> wrote: > > > I could make ours do that, or I could export NOSPACE=1 at the start o > the test > > > (since each one runs as a child process now meaning environment > variable > > > assignments won't persist into other tests) > > > > or have a NOSPACE that _doesn't_ reset? > > NOSPACE already doesn't reset, I've been doing shell prefix assignment to > set it > for individual commands, ala: > > $ NOSPACE=1 bash -c 'env | grep NOSPACE' > NOSPACE=1 > $ echo -n $NOSPACE > $ > > If I just NOSPACE=1 on its own line it should apply to all the tests in the > current script, then clean up at the end because each test script runs as a > (child process) with its own environment. > > And that's probably correct here because diff -b ignores changes in the > AMOUNT > of space but not the EXISTENCE of space, so "a b c" and "abc" still > wouldn't > match, which is what I was worried about. (I thought -b yanks space, but > instead > it normalizes it.) > > > 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). > > Sure, but that said some tests _DO_ care about the exact amount of > whitespace > (are columns aligned), or tabs vs spaces. > 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... CANONICALIZE_SPACE_IF_RUNNING_HOST_VERSION=1? so we trust ourselves but no-one else? :-) > > (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?) > > > > > > but that weakens the test, or maybe > > I could add a "NOTRAIL=1" that runs the output through sed 's/[ > \t]*$//' or some > > such? > > > > Anyway, reviewing commands to promote them out of pending is a > thing, and I'm > > trying close tabs rather than open more just now. > > > > (i didn't even realize there was a hexdump in pending! missed that > somehow...) > > It mostly comes up when I complain we've got FOUR hex dumpers that share > no code > (it's the fourth, you added the third with xxd, posix od and my hexedit > were the > first two), but the recent revisit tipped me over into "alright, I'll > clean it > up..." > > The problem is "dump hex" isn't a big enough job that pulling it out into a > library function that can be shared is really a win. It's another one of > those > "the fighting is so vicious because the stakes are so small" things. Maybe > if I > could genericize the "show hex in 4 digit groups, now do octal!" variants > into > some sort of engine... but I worry that the glue to call the engine would > be > bigger than any savings. > 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.) > *shrug* Punt that for a potential post-1.0 cleanup pass, and lump it in the > meantime... > 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 :-) > > Rob > > > > P.S. In THEORY the chmod +x bit on tests/*.test is the equivalent of > "pending", > > where "make tests" only runs the ones marked executable but you can > still run > > them individually/standalone with "make test_commandname". In > practice, the > > pending status of commands and the pending status of TESTS isn't a > 1-1 match up. > > Yes I saw your email in the other thread about pending not being granular > enough, but didn't really have anything coherent to say in response? I see > pending as an unfinished todo heap I need to drain, and I feel bad for not > cleaning it up fast enough. Doing non-cleaning work there is like > organizing > trash piles. Attempting to categorize the bulk wasn't an unambiguous win > even > for toys/ which is _intended_ to keep growing rather than shrink, so > adding it > to pending doesn't appeal. I don't really want spend architectural design > cycles > on scaffolding that gets torn down again. > indeed. 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: "toys/pending/diff.c", "toys/pending/expr.c", "toys/pending/tr.c", ... "toys/pending/brctl.c", "toys/pending/getfattr.c", "toys/pending/lsof.c", "toys/pending/modprobe.c", "toys/pending/more.c", "toys/pending/stty.c", "toys/pending/traceroute.c", "toys/pending/vi.c", :-) 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 :-( > Rob >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net