Michał Górny posted on Fri, 10 Aug 2012 09:43:26 +0200 as excerpted: > On Fri, 10 Aug 2012 05:04:40 +0000 (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: > >> Michał Górny posted on Thu, 09 Aug 2012 22:47:38 +0200 as excerpted: >> >> > Or anything else what can be spawned for shell. And a lot more what >> > you won't expect. And guess what, people are actually doing crazy >> > things with it because someone forgot to tell them how a init.d >> > script should work. >> >> Sounds interesting. A couple quick links to examples of what you had >> in mind would be nice. =:^)
> vdr is a first example which comes to my mind. They workaround program > configuration limitations and the init.d scripts become a complex > extra-configuration parser + plugin loader. Well, another thing here is > that upstream AFAIK is not willing to cooperate to fix their config > parsing. > > 'oldnet' is an another example. I'm not saying it should go; I'm saying > it should be a stand-alone executable called from the init.d script. > > Last time I looked, squid init.d was performing post-inst in start(). > Many users may find that beneficial but that's not what init.d scripts > should be doing. Thanks. (As I said my intent wasn't to start a subthread on it, but just to see where you were going with the comment, as it was rather opaque to me as it stood. Oldnet was an especially useful example here given that I run openrc-9999 to more closely follow individual commits, and I've traced and reported a few bugs in oldnet over the years. Now that I know where that comment was going, I'll shutup and contemplate.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
