Re^2: Accessing cron job output from a web page?

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

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]