Cover V03, I02
Article

mar94.tar


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?