On Mon, Jun 16, 2008 at 7:21 AM, James Carlson <james.d.carlson at sun.com>
wrote:
> The only reason I can see to support rc scripts is to allow for
> compatibility with older releases of Solaris (or perhaps even with
> other OSes). In that case, you _have to_ live with the constraints
> that those older releases continue to have -- which means that
> "#!/bin/ksh" just isn't going to work.
Consider this on an OpenSolaris 2008.05 box:
$ cat /tmp/shscript
#! /bin/sh
if [[ a = a ]] ; then
echo "This looks like Korn shell"
fi
$ /tmp/shscript
This looks like Korn shell
If I were running that on Solaris 10 or earlier I would expect:
[[: command not found
There are already incompatibilites going backwards. Generally this
has been accepted so long as old stuff doesn't break.
> An rc script should just start the service; it shouldn't be a magnum
> opus. Frankly, I think that if you're doing anything in an rc script
> that is so complicated that the difference between legacy Bourne shell
> and the newer Korn shells makes any real difference, then you're doing
> something deeply wrong.
Agreed. However, many people that need to deliver a start script
don't know about these differences - many of which only exist in
Solaris. A script that works fine on RHEL, HP-UX, and likely others
will fail on Solaris. As a closely related example, when a certain
market-leading data warehousing company's software is installed on
Solaris it drops things like the following in /etc/profile:
export VAR=val
I've seen similar things in rc scripts many times, usually when they
are expecting the shebang to have the typical effect. This is quite
likely because Solaris is not the primary development platform. The
code works just fine everywhere else, so I can understand why someone
trying to deliver to Solaris as a non-primary platform will get
tripped up in their attempts to port to Solaris. There is no value in
not supporting such an enhancement.
--
Mike Gerdts
http://mgerdts.blogspot.com/
