On Wed, 2002-04-17 at 15:24, drieux wrote:
>
> On Wednesday, April 17, 2002, at 11:55 , Chas Owens wrote:
> [..]
> > Oopsy, forgot the sleep call. That is what I get for just posting code
> > without testing it first. Well, I did say something like this <grin
> > />. Maybe it should look more like this (actually it shouldn't, you
> > _should use cron or the NT equivalent):
> [..]
>
> Hugs and Kisses - smooch, smooch, love you any way....
>
> running them from cron means that in the morning there will be
> email about what the job did... great for those 'needs to
> run around or after midnightish' types of stock sysAddStuff.
>
> Not good for folks who want to have their automation run more
> often than once a day, since the spam mail can get annoying.
So you never heard of redirecting? A typical crontab entry around here
looks like
#run every minute of everyday
* * * * * /some/misc/script.pl > /some/log/dir/script.log 2>
/some/log/dir/script.err
>
> So the generalized leap towards a deamon was a practicalish
> approach towards a generalized solution...
Only if the code is really a daemon. I have a few daemon scripts that
perform actions on request and then sleep a number of configurable
seconds, but most "we want this to run a few times a day" requests
should be sent to cron or the equivalent.
>
> but the moment that I saw the 'fork' there - I got way
> worried, since I did not see any of the classics that
> i expect when creating a daemon - such as dealing with
> the STDIN/STDOUT/STDERR - setting process group Id, et al.
If you don't use STDIN/STDOUT/STDERR then you don't need to worry.
Daemons should only use STDIN/STDOUT/STDERR on failure to start up or
interactive mode.
>
> given that you did not provide a means to 'stop' your
> almost like a daemon... nor, for that matter provided
> the appropriate 'init scriptology' such that it would
> always restart on reboot..... and ....
Did you miss the "$SIG{TERM} = sub { $terminate = 1 };"? Send this
puppy a signal 15 and it falls down nicely. As for automated starting
up, that depends on your flavor of Unix and is left as an implementation
detail.
>
> These are some of the simpler bits about getting around
> to writing a 'daemon' - in perl or any language - and
> folks need to think about the costs and consequences...
It is definitely a bare bones daemon.
>
> and there was NO POD!!!!
>
Okay, I like docs as much as the next guy, but come on! 31 lines of code
do not deserve POD. Now if this were a full fledge daemon (ie it
contained the script instead of systeming it) I could see a point to
including some POD.
> Bad, Bad, Bad Chas.... No Cookie....
Yeah, the run away script bit removed my cookie privileges for today.
>
> { ok, so I have these strict standards about what can
> be installed and run as a daemon.... }
My standards are a little bit looser (the whole STDIN/STDOUT/STDERR
bit).
>
> ciao
> drieux
>
> ---
>
> ok, so I have this other crisis - namely the bbedit folks,
> the other mailing list I am on, pointed out that there were
> these cool tricks I could do with it - and I used it as a,
>
> GASP!
>
> "Perl IDE" - to write, debug, and skank around a bit...
>
> is there an official place to get therapy to help me
> deal with the idea of a Perl IDE????
Most people go to alt.sysadmin.recovery for that.
>
> Orthodox Perl, this I Grok,
> "Perl IDE".... this hurts...
You think that is bad? How about Visual Perl
(http://www.activestate.com/Products/Visual_Perl/).
I actually liked Komodo (incremental compiling is cool), a Perl IDE
based on the Mozilla code base, it was just too slow for my 600 Mhz PC
so I switched back to VIM with syntax highlighting.
--
Today is Boomtime the 34th day of Discord in the YOLD 3168
Or not.
Missile Address: 33:48:3.521N 84:23:34.786W
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
