Shell Programming and Scripting

Hi,

i must admit that am naive to scripting.

I got one shell script created which worked fine on linux.
Later i was told that this script is to run on MP-RAS(aka NCR Unix), which is quite an old version of Unix i understand.

in the shell script that i got created, i have made use of the mmin option of the find command.
now the problem is - this mmin option doesnt work on MP-RAS platform.

If i share the shell script in this forum, then can you please try redesign this shell script to PERL? the script is not a long script.

If anyone can please help me, let me know, i shall then post the shell script describing the requirement as well with it.

Thanks and Regards,
Utkarsh

Thanks Ygor.

Just thought to share the requirement as well with you.
I have 40 files that i need to keep parsing at regular intervals for a Specific Keyword if that appears.

"within the same single directory there are 41 log files to be monitored for a specfic KEYWORD at regular intervals.
These log files have .log as their filename extension. the content of these log files is in human readable form.

Now there are chances that ALL the log files may be updated in regular intervals with their respective application writing into them or may be just a few would be getting updated. now say for example, if the log files are read for the specific KEYWORD at regular intervals of 15 minutes as per the following schedule for example:

The first, very first time i implement this solution and run the Script(to look for the Log files content) say the time is 10am.OK. at this point of time the script would run and may be Parse through the content of ALL the log files and If or Whichever LOG file(s) it find the KEYWORD it would ALERT(by writing into some other file or watever the logic you use for this capturing).

OK at this point of time , at 10am, all the log files are parsed and the keyword matched for and alerted by the monitoring application.

NOW, the second time the monitor script runs is say at 10.15am. NOW, this monitor script SHOULD be ABLE TO ONLY AND ONLY look for and parse the CONTENT of ALL such LOG FILES which have got UPDATED after 10am(or in genral terms- THE previous RUN of the monitor script) till 10.15am.

say for example if ALL or some of these 41 log files got SOMENEW content as update after 10am, then the monitor script should ONLY Parse and MONITOR for the KEYWORD in the NEWLY added/appended content of the MODIFIED log file(s).
Say for example, when we run the script FOR THE VERY FIRST TIME (whenever we implement this solution)say at 1.00pm, then it should by default parse/read the content of all the 41 log files.and in this case, in which ever log files it finds the Keyword "ERROR", it would Alert for this keyword for all such Log files.
Coming back to our scenario. Now(however we define the schedule) say we get the script to run at 1.15pm as its next scheduled Run. then the SCRIPT SHOULD ONLY PICK UP the MODIFIED files within this FIFTEEN minutes interval. WATEVER the script has found till 1.00PM should NOT be considered NOW as this would have already been alerted for such log file at the 1.00PM run of script. Hence, the application team would be alerted for such log files through a ticket which our monitoring tool would generate for them at its 1.00 PM schedule. right.

similarly, when the script again runs at say 1.30PM, then it should ONLY look for the Log files that got MODIFIED between 1.15 PM to 1.30 PM. say, out of 41 log files may be ALL these are modfied or ONLY some are modified. WHICHEVER Log File(s) are modified between the scheduled 15 minutes RUN of the Script, pick up such FILES, LOOK for the APPENDED(newly added) content in the past FIFTEEN minutes ONLY and FIND if there is any ERROR keyword in such picked up files and alert for those. so the RUN of the script would be scheduled for 15 mins or 20 mins as per our choice."

Does mtime work in PERL, if relevant to this requirement of mine.
Incase you have any doubts on the requirement part please feel free to let me know.


Regards,
Utkarsh

Is this a different problem from the original problem with which the thread was started?

You could use grep -c to get a count of errors for each log file, and compare that to the counts fifteen minutes earlier. Something like...

Code:

if [[ ! -f errors.txt ]]
then # 1st time
   grep -c $RANDOM~~$RANDOM *.log > errors.txt
fi
mv errors.txt errors.old
grep -c ERROR *.log > errors.txt
comm -13 errors.old errors.txt | while read ERR
do
   echo do something with $ERR
done

Just for fun, I thought I'd test it out...

Code:

$ cat sh.1
if [[ ! -f errors.txt ]]
then # 1st time
   grep -c $RANDOM~~$RANDOM *.log > errors.txt
fi
mv errors.txt errors.old
grep -c ERROR *.log > errors.txt
comm -13 errors.old errors.txt | while read ERR
do
   LOG=$(echo $ERR|cut -d: -f1)
   CNT=$(echo $ERR|cut -d: -f2)
   if [[ $CNT -gt 0 ]]
   then
       echo do something with file: $LOG which has error count: $CNT
   fi
done

$ echo ERROR > A.log

$ echo okay > B.log

$ sh sh.1
do something with file: A.log which has error count: 1

$ sh sh.1

$ echo ERROR >> B.log

$ echo ERROR > C.log

$ sh sh.1
do something with file: B.log which has error count: 1
do something with file: C.log which has error count: 1

$ echo ERROR >> A.log

$ echo ERROR >> B.log

$ sh sh.1
do something with file: A.log which has error count: 2
do something with file: B.log which has error count: 2

$ echo ERROR >> B.log

$ echo ERROR >> C.log

$ sh sh.1
do something with file: B.log which has error count: 3
do something with file: C.log which has error count: 2

$ rm errors.txt #--reset

$ sh sh.1
do something with file: A.log which has error count: 2
do something with file: B.log which has error count: 3
do something with file: C.log which has error count: 2

$

No matrixmadhan... this is the same problem for which the thread was started.

---------- Post updated at 10:20 PM ---------- Previous update was at 10:18 PM ----------

Thanks Ygor.
I should try the option/suggestion given by you.
really thanks for this...would let you know of the results if meeting my expectation or we require some more improvement on this...