Michal, The testsuite so far was used (at least by me) this way: I change something in hush.c, I build busybox, I cd to shell/hush_test, I run ./run_all.
You are using it in a different way. This is good - it's beneficial if hush is tested more ways. But this inevitably means you will see some things in testsuite which are not working in _your_ setup. Because they were never tested that way. You are fixing testsuite to make it work in your usage case. What you need to take care of, though, is to _not break it for existing use case_. That is to say, you canoot assume that the system you run tests on is using busybox, let alone it is using busybox with the same config. > ps -o is supported in busybox only with CONFIG_DESKTOP option. Yes. But the system you run tests on may not only have different .config, it may actually have _non-busybox_ ps! Here, ps -o was used delibarately because -o option is mandated by POSIX etc. It is not too unreasonable to assume it is available. However, this can be fixed just by moving to by far more robust facility for measuring leaks: memleak debugging builtin. I will do it. > negate test: > There were hardcoded path to /usr/bin/printf but > when is CONFIG_INSTALL_NO_USR enable is printf in /bin folder. Same here. But here (unlike ps -o), we can simply try to autodetect where printf is using "which printf" Please try attached patch. -- vda
7.patch
Description: Binary data
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
