Someone recently asked me about increasing command width for ‘ps’ on SCO Unix.
I thought I had the answer at Best of CUSM: width of command in ps, but it turns out that post was incorrect as a more recent newsgroup discussion explained. The SCO ‘ps’ is stuck at 80 characters.
The actual problem related to BBX. Apparently this gets run with very long command lines, but the part this person wanted to know about is at the end of the line – way out of the 80 character limit ps has here.
My immediate thought was to front-end BBX with a program that would capture the arguments and store them somewhere convenient. In Perl, that might look something like this:
#!/usr/bin/perl
$args=join '-',reverse @ARGV;
# just for more convenience
if ($pid = fork) {
open(O,">pid.$pid");
print O "$args\n";
close O;
waitpid($pid,0);
unlink "pid.$pid";
} else {
sleep 3600;
# actually here you'd exec the real program,
# this is just a concept script
exit 0;
}
If you wanted to be even fancier and not use a file, you could fork off yet another program with more convenient arguments:
exec 'bbxmatcher', $pid, $args;
That bbxmatcher would do nothing but sleep; you’d kill it off when the real bbx returned. Then a “ps -e | grep bbx” would display just what you wanted – perhaps sometimes slightly out of order, but often not, and easily identifiable.
You’d end up being able to do something like this:
$ ps -e | grep bbx
The “bbxmatcher” tells us that the ending argument of pid 8971 was “SOMEPROG”, and could tell us other things too, if we wanted.
For production use there’s probably a bit more you’d want to do, but this is the basic concept. I don’t know if this meets the original person’s needs, but maybe it could be used in other situations. You could arrange the arguments however you like, add extra information in more convenient formats and so on. Could be helpful for someone..
*Originally published at APLawrence.com
A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com
