Re: Accessing cron job output from a web page?

A more general solution might be to write an event logging module and 'use' it in all your scripts. Then any time something 'happens' you can invoke an API in that event-logging module and log it to a file (or better yet, a relational database). Hey, presto, you've got a decent historical picture of what has been happening. You can write the CGI script that presents the 'current picture' once and make it configurable/filterable for various slices of the event log.

Or you could stick with your cron log-sweeping idea, especially if you have a lot of shell scripts. The above is just an idea that popped into my head, and may not be well-thought-out. Take it or leave it. :)

No good deed goes unpunished. -- (attributed to) Oscar Wilde

Comment on Re: Accessing cron job output from a web page?

Replies are listed 'Best First'.
Re^2: Accessing cron job output from a web page? by OfficeLinebacker (Chaplain) on Apr 19, 2006 at 22:04 UTC
I'll leave it, thanks. ;) (Hope that kind of humor is accepted here) Some of the scripts invoked by cron are shell scripts. I think about 50% are perl, and the rest csh (I know, I know--that's the default here). Also, I'm probably not experienced enough to write a module, and I don't really know what an API even is. We do, however, plan to use perl wrappers for all 'interesting' cron jobs, the main purpose of which is to mark the STDERR output to distinguish it visually from the STDOUT on the web page. The CGI thing seems more and more intriguing; unfortunately I have much less experience with CGI than regular perl, plus CGI is kind of a pain the way they have it configured here. I think I may propose to keep the "sweeping" algorithm for now, but think about upgrading in the future. Thanks for any and all comments! :) -Terrence	[reply]
Re^3: Accessing cron job output from a web page? by ptum (Priest) on Apr 20, 2006 at 17:45 UTC
Heh. It is certainly accepted by me ... PerlMonks is a dull place if nobody has a sense of humor. SOPW is sort of like an advice buffet -- take as much as you like of whatever suits you. :) API simply stands for 'Application Programming Interface' and has to do with the external 'face' or 'handle' that one application presents to another who wants to use its functionality. So (in my hypothetical example) the event logging subsystem would conceal its complexity from its clients and present an easy way to log events by simply instantiating an EventLog object and calling some simple method. The EventLog.pm module might have all kinds of cool and intricate private methods that stored away the events in files and databases, but all that would be 'under the covers' and the scripts that called that method wouldn't have to know about it. I like the sound of aufflick's idea, in that it might combine the best of both worlds -- working with shell scripts and having minimal impact on your existing scripts, yet being extensible in terms of parsing and reporting on the event messages once they've been mailed. No good deed goes unpunished. -- (attributed to) Oscar Wilde	[reply]