enh dixit: [ mksh testsuite ] >have you considered using sh instead? :-)
Not pure sh, that’s nowhere near enough. Maybe mksh. But if the one just built has issues, that may mask it. If another, you’ve got hen/egg problems. Maybe C. But then, (cross-)building a C program to test another one just built *may* (or may not) be more susceptible to errors than using a completely separate tool. No, I’m not happy with the current testsuite driver, but it’s there, it’s reasonably portable, and does its job, after some prodding (and I still don’t speak Perl). >(there's no perl on Android, which makes running the mksh tests >impractical. one can *build* perl for Android, i'm led to believe, but I’ve successfully (modulo the things that just didn’t exist, or didn’t work with toolbox) run the testsuite on Android (on the emulator) once, with a native Bionic perl. Nowadays, I’d probably just get a Linux/ARM box (Debian poterbox would be superb, except I retired from Debian recently), build a native Perl against dietlibc or musl, statically, then copy that over to Android, as it only relies on the kernel, and this is enough for the testsuite. Another idea we will have to try out: check if the testsuite can be run on the build system (instead of the target), using ssh (or adb shell) to invoke the to-be-tested utility on the target. Con: we’d probably need to NFS-mount or rsync the directory tree. But maybe something the *WRT people are also interested in. (Or we could move file generation to the target as well. Needs more hacking work in the testsuite driver.) Anyway, this is still enough short-term. bye, //mirabilos -- “The final straw, to be honest, was probably my amazement at the volume of petty, peevish whingeing certain of your peers are prone to dish out on -devel, telling each other how to talk more like a pretty princess, as though they were performing some kind of public service.” (someone to me, privately)