New procps 3.3.0 for Debian

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.


Testing Systems

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.

Enhanced by Zemanta

5 thoughts on “New procps 3.3.0 for Debian

    1. 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!

  1. 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…

  2. 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

Comments are closed.