RHAT bug? /etc/init.d/functions:daemon()

[Paul Lussier]

Bill McGonigle <bill at bfccomputing.com> writes:

> On Feb 1, 2006, at 13:30, Ben Scott wrote:
>
>>> I didn't say you wouldn't want to use any modules, I said you don't
>>> want every module known to man to be used.
>>
>>   But then someone has to decide which modules are appropriate and
>> which are not.  I think the question of deciding which modules are
>> "considered useful" is subjective and not really possible to answer
>> correctly.
>
> It's the job of the distribution.  They make the same decisions about
> which packages to include.  Some I agree with, some I don't.  Choice
> is good.
>
>>   So now, in addition to having the "Does this platform
>> support Perl in initscripts" question, we have the "Which Perl modules
>> does this platform variant support in an initscript" question.

We're talking about a minimal perl distribution with a static binary.
It doesn't need any modules, not even the ones which come in the
standard perl distribution (well, maybe GetOpts :) Would more modules
be useful?  Sure, but we could easily survive with a minimalistic perl
which did nothing more than the basic replacement of sh.  As you
yourself said, we're taling bout init scripts here, how complicated
does it need to be?!

> Most modules contain XS code - usually written in C.  On a normal perl
> they're loaded dynamically, but that's not the right way to do
> something that has to run from /bin.

That's not entirely true, and for an init script perl installation, we
certainly wouldn't need them.

>>   So eventually I'll end up with an initscript that requires a working
>> installation of X, GNOME, a sound server, and Mozilla.  Oh joy.
>
> If you have a moron maintaining your distribution, yes.  I wouldn't
> use such a distribution.  You can do the same thing with bash scripts.

As we've seen with RH's scripts :)

>> Hell, let's just symlink /sbin/init to emacs, and do everything in
>> Emacs LISP.  ;-)

Yeah, that's been tried, but for some reason Lisp Machines and
Symbolics never really caught on.  Though I think that was much more
of a political/intellecual property battle than the technology being
bad.

> Paul will back you on this.

I'd certainly like to see more Lisp out there.  I find it to be
afacinating language with incredible potential.  Alas, my studies in
Lisp have been put on the back burner for the last couple of months
due to a more dire need to look at things like Java and playing with
perl's DBI::Loader stuff :(

>>  Like I said, I rather feel that if Perl would help that much, you're
>> not writing an initscript, you're writing a full-blown program.
>> initscripts aren't supposed to be big, complicated things.  They're
>> supposed to start and stop services.

True, but perl is (and I can't believe I'm saying this) easier to read
most of the time than bash init scripts.  Of course, given that most
of the init scripts would likely be written by the same people writing
them now, we really will end up with unreadable line noise in our init
scripts.

> Yet they can be cumbersome to write in bash, even for those of us who
> know bash.  If you've never said, "gosh, this would be so much easier
> in..." while hacking bash scripts then you get a pass on this one.
> Sometimes when you start stuff you need to check for error codes,
> error messages and successes.  How many init.d scripts have you seen
> that print [OK] when the process has segfaulted or [FAILED] when it's
> actually worked?  I see this all the time.  I propose that if bash had
> good, easy text processing many more programmers would write good init
> scripts that actually worked.  Having a system full of half-working
> init scripts shouldn't be acceptable.

bash has great text processing in sed, awk, tr, and the like.  But can
you use them from init scripts?  Perl would definitely provide for
this level of text processing.  It would also allow for mushh better
debugging, which is overly difficult with sh, where the best you can
do is -x and a liberal use of echo (which, arguably, is all you need
most of the time ).

-- 

Seeya,
Paul