Hi, > >> When I want to restart a service like "named", I don't have to > >> do any manual parsing; I just run "/etc/rc.d/named restart". > > This is the easiest case. But say, you have several > > rc_directories and you want to know if a specific additional > > service is enabled, which does not have the same name as its rc > > variable. > > Then you have to parse rc.conf, check all rc directories, check > > their rc variables, evaluate their rc variables and names and > > then check back rc.conf whether it is enabled. > > No, I don't have to parse anything. Whatever external source gave > me the knowledge that this additional service exists should have > also told me how to start it. So I just do whatever it is that's > needed. > > Are you postulating a use case in which you know the script name, > but don't know the directory or variable names, and you can > nevertheless assume that the script follows most or all of the > same conventions as the scripts supplied with the base OS? I'm talking about the other way round: You have the name of the service (or even only the rcvar), but not the script name. Something that 'should' be given is something you cannot rely on. All in all, this is just about usability. Not having to specify the full path for restarting a service by hand. > > But, though it might be bad style, there's also the name > > variable in each rc script, still forcing you to check all > > scripts. > > If there is e.g. no /etc/rc.d/named, you would have to check all > > files in all rc_directories by hand for the name named you're > > looking for. > > Either a few lines of sh code or one bad-ass line of sed-sh-mix. > > I still don't understand this. What might I be trying to do, and > what might I already know or not know, such that the next step > towards solving my problem is "check all the scripts"? What args > would you pass to your wrapper to tell it exactly how to check all > the scripts? you're right, service(8) doesn't do that exactly. My fault, sorry. As I said: I didn't want this discussion grow that large, I just thought it might be usable - and perhaps wanted, as was stated in the thread some time ago, but just not finished. Regards, Julian
Attachment:
signature.asc
Description: PGP signature