| Recent
Articles |
A Ps Problem With BBX
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...
Creating Perl Modules for Web Sites
When you are writing your own code, you are more apt to use someone else's module
than write your own, unless your project gets fairly large and complex. Small
scripting tasks just don't need the advantages modules offer....
EMEA Ditching Perl, Python, PHP?
A spring 2005 survey of developers in Europe, the Middle East, and Africa finds
a dropoff in their use of those three languages. The June survey of 400 developers
by Evans Data Corporation revealed fewer developers...
Bit
vector, using Perl vec
A bit vector is just an array of bits; subsets of bits within the bytes have some
meaning. That allows more compact storage for certain types of data. For example,
if you only needed boolean on-off values, you can store...
|
|
|
02.14.06
A Ps Problem With BBX
 By
A.P. Lawrence
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:
$
./bbx args args args args args args args args SOMEPROG &
$ ps -e | grep bbx
8970 p2 S+ 0:00.02 /usr/bin/perl ./bbxmatcher 8971 SOMEPROG-args-args-ar
8971 p2 S+ 0:00.00 /usr/bin/perl ./bbx args args args args args args
arg
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
|
