New Messages
To: saletter@rdpub.com
Subject: Not Finding What One is Looking For
In his article "checkcron: Checking for the Unexpected,"
Steven G.
Isaacson correctly mentions that when using 'grep' against
the output
of 'ps', one must be careful to weed out the grep command
itself in
the filtered output. His solution, however, is much
too large a hammer
for such a small gnat.
Mr. Isaacson suggests using:
ps -furoot | sed '/grep/d' | grep cron
when all that is required is:
ps -furoot | grep '[c]ron'
This method simply uses metacharacters to force an expression
to not match itself.
T. Mike Howeth
System Administrator
CompuTrac, Inc.
tmike@cmptrc.lonestar.org
Thanks for the fine-tuning.
Dear Sirs and/or Madams:
I tried the programs listed in "Reading beyond
a Bad Header with tar,"
in the Nov/Dec '93 issue. I believe there may be a error
in lines
29 and 34 of passPart.c. In both cases, the size variable
being passed
to realloc() is (*Pn)+1. This is just the count of array
positions;
to be the number of bytes required, this quantity must
be multiplied
by sizeof(int), much like what is done in lines 24-25.
Until I made
this change, the program core dumped at this point.
Larry Hofmann
NCR: San Diego Porting Center
larry.hofmann@SanDiegoCA.NCR.COM
Ben Reaves replies: You mentioned an error in lines
29 and
34 of passPart.c, from the article "Reading beyond
a Bad Header with
tar" in the Nov/Dec 93 issue of Sys Admin magazine.
You are correct.
When I in first used this method for the large tape
described
in the introduction of the article, the function of
passPart.c was
performed by a messy and slow shell script. I rewrote
it for the Sys
Admin article and tested it on a smaller example, which
did not show
any signs of trouble with the faulty realloc arguments.
The corrected lines of passPart.c are:
29 *PPstart = (int *) realloc (*PPstart, sizeof(int)*((*Pn)+1));
34 *PPend = (int *) realloc (*PPend, sizeof(int)*((*Pn)+1));
Thank you for bringing this to my attention.
To: bjorn@sysadmin.com, saletter@rdpub.com
Subject: Capturing Monitor Output to a Printer
As a new subscriber to Sys Admin, I must tell you it
is an excellent
journal with worthwhile contributors and information.
I work for the Federal courts and we are in the process
of converting
from a Unisys (95/5000) minicomputer to a high-end 80486
PC running
Interactive Unix. On the Unisys, we had a dedicated
console port,
to which we attached a dumb terminal (as you will read,
this "dumb"
terminal was not so dumb after all). We set the console
to "auto print"
and attached a simple dot matrix printer to the console's
printer
port. This allowed us to capture on paper all of the
console messages,
hardware panics, diagnostics, bootup and shutdown progress
and lots
of other goodies (such as failed logins).
The new PC is just that -- a PC with a VGA/monitor port
that drives
a standard VGA monitor. My question is what do I need
to do to also
capture the console messages onto a printer? We are
aware of the "alternate
console" concept with UNIX, but there will still
be a plethora of
messages that are not directed to /dev/console but will
only appear
on the "PC's monitor."
Are there any hardware (or software) solutions that
will send the
console monitor's signal to both the console monitor
AND a printer?
I know devices exist to split the signal and send one
signal to LCD/Overhead
Viewers or to convert the signal into video (for TVs),
but this doesn't
solve our problem.
Steve Kaplan, Systems Manager
steve@cadc.uscourts.gov
U.S. Court of Appeals for the D.C. Circuit
Thanks for the kind words about Sys Admin -- readers,any
pointers on
how to get this done?
|