For the second question, the answer is no and you should have a look at Resources for portable shell programming.
As for the first part - first of all, you certainly have to be careful. I'd say perform several tests to make sure - because the fact that someone does have systemd (for ex.) installed, does not mean it is actually used as the default init. Also, looking at /proc/1/comm can be misleading, because some installations of various init programs can automatically make /sbin/init a symlink hardlink or even a renamed version of their main program.
Maybe the most useful thing could be to look at the init scripts type - because those are what you'll actually be creating, no matter what runs them.
As a side note, you might also have a look at OpenRC which aims to provide a structure of init scripts that is compatible with both Linux and BSD systems.
I've now found that the issue was that the service file automatically generated by systemd-sysv-generator lacks an install section with a WantedBy option. I added the following to my generated file at /etc/systemd/system/programexample.service which allowed me to properly enable the service:
[Install]
WantedBy = multi-user.target
After that I ran
systemctl daemon-reload
to ensure my service file was read by systemd.
Now I received a proper notification that my service was actually symlinked somewhere to be "enabled":
[root@centos7-box ~]# systemctl enable programexample.service
Created symlink from /etc/systemd/system/multi-user.target.wants/programexample.service to /etc/systemd/system/programexample.service.
This link helped me better understand the service file.
I am not a fan of the way that systemd-sysv-generator does not include an install section with a WantedBy option by default. If systemd can dynamically read the LSB headers and properly start services at boot, why doesn't it generate the service file accordingly? I suppose some systemd growing pains are to be expected.
Update July 7 2020:
Working with Debian Buster and trying to enable a SysVInit legacy service, I was presented with this wonderful message, which I believe would have saved me some time when I dealt with this issue in 2017:
Synchronizing state of programexample.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable programexample
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template units). This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.
Best Answer
Some distributions have opted to include compatibility scripts so that old style commands still work. For example, on Debian 8.