[mass cc cleaning; does this belong in -policy?] Ethan Benson wrote: > > On Fri, Jul 07, 2000 at 10:44:15PM -0400, Christopher W. Curtis wrote: > > > > My idea is to have a script, '/etc/init.d/defaults', which every init > > script sources. 'defaults' will read the default settings and define > > common functions for the scripts to use. Here is a rough draft of the > > this is exactly how redhat does it and it **S U C K S** > there should be shell variables thats *IT* > > no fscking functions > no fscking sourcing (except for the init script sourcing its *ONE* > config file (which contains ONLY simple shell variables)
Why do you feel this way? A lot of the debain scripts contain stuff which seems non-obvious to me, and they (pretty much) all do the same few basic things: start programs, stop programs, and display messages. Why is it wrong to combine these? Furthermore, making it a policy to source one config file (it should be two - one default, one user override) to read a bunch of environment variables would make a lot of the scripts even more confusing/convoluted then they already are. That just doesn't seem like a good thing(tm) to me. > no all scripts should only include the script config file > /etc/default/portmap (or whatever) Also realize that some packages contain more than one daemon. > > doing so. The script will make sure the the environment for running the > > package is sane, and provide functionality to start any programs it > > needs (start) and to send them various signals (hup, usr1, etc). It > > noooooooo! this is the horrible crap redhat does. its buggy, broken, > obfuscated, crap. /me considers moving to slackware or *BSD.... sheesh. Look at the tarball I sent as a followup - it's really not that complicated, and it can still be up to the script writer to chose to use it or not. I have a total of five functions: start(), status(), generic_kill(), then hup() and usr1(). The only other thing that I can see wanting to be added is more signals - eg, kill(), and usr2() - and these constitute a mere 5 lines of code each, including comments. > [snip obfuscated ball of redhat spaghetti] Come now - I've had to deal with RedHat init scripts and this is nothing like them (nothing like the ones I had to debug in 4.2 or 5.2, anyway). One sourced file from the init script. That file sources a default and user option file sitting in defaults.d/packagename. The goal is that these files are the real variables, and nothing more. Sourcing the 'defaults' file simply handles it for you, adds a couple extra checks that would have to go into the script anyway, then provides a few functions which I think should be encouraged but which need not be used. > apologies for the flame but one of the *primary* reasons i switched to > debian is to escape redhats fucked up initscripts which you just > described in your proposal. RedHat goes far beyond what I've done ... Christopher [The code actually allows commandline arguments to be passed into the file containing only variables; so yes, it could get confusing, but it was trivial to add and might just be useful for some scripts so I left it in. Better to err on the side of flexibility in this case, methinks.]
