Coming soon after the upstream procps 3.3.0 being released, the Debian packages have been uploaded tonight. The Debian packages have had the added benefit of being a day late by having a tiny 2 line patch to stop pgrep from crashing.
One regression that is on purpose, watch is currently not 8-bit clean again until I can sort out how to get the linking right with the new build process.
The embarrassing problem with pgrep did start a discussion about testing, especially regression testing. I’ve recently started using unit testing in my python programs and love the level of assurance those tests give me that I haven’t broken anything (to a degree anyhow). I’d really like to be able to type “make test” and have each of the programs run through a series of tests.
The problem with packages like procps (psmisc too) is that you really need to test the entire program, not just a stub, and that the program needs access to a know level of /proc. The only thing I have seen that is even remotely what is needed is the bunch of scripts that coreutils uses which creates dummy files and directories to operate the commands on. I expect we could do something similar with some scripts that create a known process but if anyone has a better idea about how to test a command line program let me know.
Maybe a naive answer, but wouldn’t DejaGnu do the trick? See http://www.gnu.org/s/dejagnu/
Not a naive answer in the least! I’ve had a look at that program and it looks like it will do exactly what I am after. I was looking around for something like this for psmisc for the same reason and couldn’t find anything for command line programs.
I’ve already made a simple series of tests for pwdx and, while dejagnu has the same documentation problems that most GNU programs have, it is a very clever setup.
PASS: pwdx no args
PASS: pwdx pid 1 should give permission denied
PASS: pwdx finds sleep in cwd
Thankyou for pointing it out!
Glad to have helped 😉
While we’re at it, you may even consider coupling dejagnu+valgrind, as currently done in LLVM testsuite: http://llvm.org/releases/2.7/docs/TestingGuide.html
Another idea would be a testsuite based on PID namespaces – this would give a very clean environment that can be populated with mock processes.
One problem I see here: Some date (like the process size) is not very static…
probably there aren’t any, but for programs that rely exclusively on /proc (as opposed to process-related system calls), you could override the default location of the proc filesystem when a test flag is set