SysV startup script name in binary RPM distribution

I'm not a subscriber to the list. Please copy any responses directly to me.
Thanks.

It's such a minor, but annoying bug, and is easily fixed:

The stock startup script included in the RPM (I currently use the 7.3.3 RPM
for RH7.3), /etc/rc.d/init.d/postgresql, sets the service name (the $NAME
variable within the script) to the basename by which it was called, with
this line:

  NAME=3D`basename $0`

This seems like a logical thing to do, but it causes a problem because the
system calls the script by its various softlinks (such as
"/etc/rc.d/rc3.d/S85postgresql" or "/etc/rc.d/rc1.d/K15postgresql").

The best example of the effect is that during a normal boot into run level
3, the service name gets set to "S85postgresql" instead of the obviously
correct "postgresql." This is reflected both on the console ("Starting
S85postgresql...[Ok]"), and in the /var/lock/subsys/S85postgresql lock file,
for example. Later when doing a "service postgresql restart" or something
similar, the script is supposed to delete that lock file but fails to,
because it *now* thinks its name is just "postgresql." That ridiculous
/var/lock/subsys/S85postgresql file just hangs around perpetually (like a
thorn in my side).

A trivial fix would be either to change the assignment to

  NAME=3D`basename $0 | /bin/sed -e 's/^[SK][0-9][0-9]//'`

and add the sed requirement to the postgresql-server package, or use two
lines, such as

  NAME=3D`basename $0`
  NAME=3D${NAME#[SK][0-9][0-9]}

which I know works with bash, but I'm not sure if it will work with an
old-style Bourne shell. Incidentally, is there any strong reason it doesn't
just standardize and become the following?

  NAME=3Dpostgresql

Thanks. Please save me the 10 seconds it takes to reimplement this fix every
time I upgrade. :)

Mike Nerone

/* The only secure computer is one that is unplugged from the network -- and
the wall. */