No, it just makes sense to use a service command. /etc/init.d ist just too cryptic. If you think it makes sense, then you are stuck in old UNIX dreams. Linux is not Unix anymore, lets move on. Linux differentiated itself from Unix for being simpler and easier to use, while at the same time not losing any power, that is what you call progress.
I thought that the service command was a great idea by RedHat when I first saw it about 7 years ago. Now I have been using /etc/init.d on Debian for 5 and there was not one day where I found it lacking.
service xzy restart ist just more intiutive and human readable than /etc/init.d/xzy restart.
There are some people that think that VI is very intuitive and that everybody should learn it, but I disagree. There is nothing that puts more newbie Linux users off than VI. VI is about 4535% more complicated than it is useful. It does not make sense to spend weeks in classes to learn how to use it, when you can get about 3 editors that do the same job easier and faster, having the “magical” features of menus built in and an intuitive GUI
If you are a VI crack, heck, use it, but don’t inflict it on newbies, if you think that the typical Ubuntu user is interested in learning VI, you are mistaken.

>However, the “service” command is really
>pretty useless. Instead of running “service

Aha, define useless? As useless as /etc/init.d/ ? It is the same. It is the same argument than you would say, instead of calling me by my last or first name, calling me by my social security number. That is also more direct, my name is after all only a alias for the SSN.
I don’t have to explain to anybody that first and lastname are easier to remember than the SSN. The same holds true with the service command.

> foo reload” (for example), simply type in
>“/etc/init.d/foo reload”. Wow, that works
>just the same, but there are a few
>advantages:

1. It’s portable. Using “/etc/init.d/foo something” will work on Red Hat, SUSE,

No, I don’t think you should do that on RedHat or SuSE, because these distros are built to use the service command. It is an abstraction to the /etc/init.d thing and should be available on all systems. Of course not on the old Unixes, but they are dying out because of that, aren’t they? Harsh worlds maybe, but on many unixes there is no progress anymore. Just sitting on the laurels and feeling good about being called UNIX. If you have ever compared TOP with HTOP, you will know what I mean. TOP is standard Unix, unchanged for aeons, no progress, still the old annoying errors (no way of seeing ALL tasks for example) and HTOP is a Linux invention (or BSD, beats me) and has “revolutionary” features like use of cursors, use of colors and intuitive usage that you need no RTFM for.

2. It’s less typing. You can use TAB (or
Yes, that may be, but more thinking. Services are services. On any OS. /etc/init.d is not self explaining.

>3. It doesn’t “lock you in” to a
>proprietary tool. OK, calling Red Hat’s
>“service” script proprietary isn’t exactly

I am an expert in vendor lock-in and trust me, this here is not lock-in. Heck, no. We are talking about a trivial free tool. It is like saying that Linux uses VI to lock-in users, so they can never go back to Windows *grin*.. quite the oposite. VI is there to scare potential Linux users off and make them return to Windows. I know a few and have had the experience myself. VI is a P.O.S. program which does not even let you exit intuitively. You get trapped and sending it a sigterm or sigkill, acompanied with the swearing “who the heck designed this ***** programm? what were they thinking?” is the normal behaviour of newbie user. How are you supposed to know that the cryptic combination :q! will bail you out? Ever used that in any other program?

>The long and the short of all this is the
>one really should just learn and use the
>“portable habit” of typing “/etc/init.d/”
>instead of “service “. Christer, I would

I disagree strongly. If you want to use it and teach it to your students, do so. I won’t. I will further the use of service, because it makes sense!

Markus

I guess it does the same thing, but I would love to have all the other tools. Thanks for letting us know about this find.

As for Lamont’s second point: with shell completion it not much more typing. invo[TAB] po[TAB] r[TAB] and postresql is restarted.

I can see one more point for using service/invoke-rc.d. See, initscripts aren’t guaranted to stay. upstart rules, D-Bus activation, Solaris SMF, daemontools, other init systems, they all do not have initscripts or have them modified. service/invoke-rc.d should be viewed as abstraction layer for them. Use “service somethin start”. Do not choose between “svcadm enable something”, “/etc/init.d/something start”, “/etc/rc.d/rc.something start”, “dbus-send com.ubuntu.upstart.Start something”, “svc -o /service/something” or billion other methods .

However, the “service” command is really pretty useless. Instead of running “service foo reload” (for example), simply type in “/etc/init.d/foo reload”. Wow, that works just the same, but there are a few advantages:

1. It’s portable. Using “/etc/init.d/foo something” will work on Red Hat, SUSE, Solaris, (Open|Free|Net)BSD, AIX, IRIX, HP-UX, zOS, UNICOS, etc., etc., etc. In other words, every UNIX and UNIX-like OS I’ve ever run into.

2. It’s less typing. You can use TAB (or ESC, ESC, depending on your shell) completion to save keystrokes and to find filenames that differ a little from one system to the next.

3. It doesn’t “lock you in” to a proprietary tool. OK, calling Red Hat’s “service” script proprietary isn’t exactly a fair characterization. For a long time, they’ve been the only ones who had it, but there is a similar implementation now available on SUSE Linux Enterprise Server and now Ubuntu. They’re doing that to help people make the transition from Red Hat a little more easily.

The long and the short of all this is the one really should just learn and use the “portable habit” of typing “/etc/init.d/” instead of “service “. Christer, I would hope that you would do that in your Red Hat classes, too. Trust me when I say that your students will appreciate that approach.

When doing /etc/init.d you may inherit some variables from the shell you call it from