== A building block of my environment: _sps_, a better tree-based process list

Once upon what is now a very long time ago, it appears back in 1987
or so, Robert Ward wrote a better version of BSD _ps_ that he called
_sps_ ([[cf
https://groups.google.com/forum/?_escaped_fragment_=topic/comp.sources.unix/s0Tg_vGSMEc#!topic/comp.sources.unix/s0Tg_vGSMEc]]).
The highly useful signature feature of _sps_ was that it displayed
processes in sort of a tree form, with UID transitions marked. This
was in the days before _pstree_ and equivalents were even a gleam
in anyone's eye, and anyways I maintain that _sps_'s display is
better than _pstree_, _ptree_, or the Linux _ps_ option that will
do process trees. I used SPS happily for a number of years on
BSD-based machines but then wound up dealing with the System V based
SGI Irix and really missed it. Rather than take on the epic work
of rewriting code that grubbed around in kernel data structures, I
redid the important features I cared about as a script that used a
pile of _awk_ code (well, _nawk_ code) to post-process _ps_ output
(using the System V _ps_ feature of printing out only specific
columns in parseable ways).

(In the process I learned a great deal about how what are now
ancient versions of _awk_ and _nawk_ handled attempts at things
like recursion and how to fake local variables.)

Ever since then I have carried my _sps_ script forward across OS
after OS (SGI Irix 6, then Solaris, then Linux), adopting it slightly
for each one. It remains my favorite way of getting process listings
on Linux (partly because I fixed [[the Linux ps problem with long
login names ../linux/PsUsernameSize]]); on modern versions of Solaris
_ptree_ is almost as good, especially since our Solaris machines
don't have users (and thus UID transitions).

([[Jim Frost wrote a Linux version of _sps_ back in 1998
http://marc.info/?l=redhat-announce&m=90949343627508&w=2]] and I
used it for a while but it has to be compiled, I don't think it's
been updated for a long time, and I don't know if it still works
on modern Linuxes. For that matter I don't know where you'd still
get the source code today.)

SPS output looks like this:
.pn prewrap on

 Ty     User            PID CMD
 [...]
        root           1192 /usr/lib/postfix/master
         |postfix      1197 qmgr -l -t fifo -u
         |postfix     22675 cleanup -z -t unix -u -c
         |postfix     22676 trivial-rewrite -n rewrite -t unix -u -c
         |postfix     22677 smtp -t unix -u -c
         |postfix      6205 pickup -l -t fifo -u -c
 [...]
        root           6899 /usr/sbin/sshd -D
         |            22741 sshd
          |cks        22760 sshd
 pts/0     *          22761 -rc
 pts/0      |         22856 /bin/sh /u/cks/bin/bin.i386-linux/sps -A
 pts/0       |        22858 ps -A -o user

This is a very small excerpt from '_sps -A_' that shows the essential
features (it's a small excerpt because modern Linux systems have a
lot of processes even if they're not doing much).

If this sounds interesting I've put my current version of _sps_ for
Linux on the web [[here
http://www.cs.toronto.edu/~cks/software/scripts/sps.linux]] and
there's also a lightly tested [[OmniOS version
http://www.cs.toronto.edu/~cks/software/scripts/sps.omnios]].
Adaptation for other Unixes is left as an exercise for the interested.

One of the reasons I quite like my script version of _sps_, apart
from its sheer usefulness, is that it shows how Unix evolves useful
capacities over time (and how more CPU power makes them more
feasible). In the BSD era _ps_ was sufficiently hard-coded and _awk_
was sufficiently limited that you'd probably have had a hard time
duplicating the C version of _sps_ with a script and if you had,
the result would have been pretty slow and resource intensive. Move
forward a decade or two and there's no serious problem with either.
Today I doubt you could measure the impact of using a script for
this and committing to modern _gawk_ features would probably make
this even easier.

(A truly modern version of _sps_ would probably use Perl instead
of trying to mangle everything with _awk_ and other shell tools;
Perl is now ubiquitous enough to make that perfectly viable.  Since
I'm not really fond of Perl, I'm not the right person to write that
version of _sps_ but feel free to go wild. I'd expect a Perl version
to be smaller, better, and possibly faster.)