httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: Suggestion: shtool
Date Tue, 27 Apr 1999 20:10:33 GMT
Ralf S. Engelschall wrote:
> In article <> you wrote:
> > Ralf S. Engelschall wrote:
> >> In article <> you wrote:
> >>
> >> > [...]
> >> > At least for Apache 1.4/2.0 it sounds reasonable to use shtool, of course
> >>
> >> Although I'm rather sure Jim will not change his general opinion on shtool ;),
> >> here is the final note at least for the group that shtool 1.1.0 was released
> >> today. It's a complete overhauled version for which I've spent 25 extra hours
> >> over the weekend. It now even includes a complete manual page covering all
> >> tools and options, it contains a small GNU autoconf environment for building
> >> and installing, I've cleaned up and merged the ingredients, added a few more
> >> goodies from my script archive, etc. So, at least those interested in such
> >> tools (especially for other Open Source packages) should look at it and take
> >> again my suggestion that for Apache 1.4/2.0 one should consider replacing most
> >> of our current scripts with shtool calls.
> >
> > I still don't think that a single script is an advantage, modules exist
> > for a reason. Also, I totally agree with the comment about libtool - if
> > it works its great, but if it doesn't it seems to be totally impossible
> > to fix (and, in my experience, it doesn't). I haven't looked at shtool,
> > but the fact it is a single script does not bode well.
> It's not really fair to not look at the code but to give a general mark on it
> just because it's a single script. That sounds as would all single scripts be
> bad which is like saying any single executable not using DSO for its parts is
> bad IMHO. Hmmm... I would appreciate more closer looks at the package before
> it is given a mark.

I repeat: modules exist for a reason. I do not need to look at your
script to know it could be modularised, since it appears to be a design
aim to demodularise it. That is sufficient reason to not even bother to
look at it. If something is based on bad design principles, it is simply
not worth my time to look at the detailed design.

> > I'm also not keen on relying on externally maintained packages, any more
> > than is necessary, even if it does mean a little more work for us. That
> > is, unless they are _extremely_ widely used (i.e. already installed
> > nearly everywhere).
> That's IMHO confusing when you talk about shell scripts: Because you always
> depend on lots of _external_ and even not always portable programs when you
> program shell scripts. So, when you don't want to rely on external things in
> general, you've to package Perl with Apache, compile Perl yourself at the
> bootstrapping phase and then program anything with this Perl interpreter and
> without any Perl modules, etc. Then I can accept this argument.

Perl falls into the "extremely widely used" category. I can expect it to
work on most platforms.




"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi

View raw message