On 8/4/07, Rene Cunningham <rene at terdmonk.com> wrote:
> Hi,
>
> Im designing a package that uses a bash postinstall script to handle various
> tasks.
Since bash is not available in installation miniroots (e.g. during
jumpstart) and is not included in the smaller installation clusters,
trying to use it is likely to be problematic. If you need something
with more features, perl is available in all of these circumstances.
> Reading the 'Application Packaging Developers Guide'[0], it states that
> installation scripts must be executable by the bourne shell.
Much like /etc/rc*.d scripts, they are called explicitly with /bin/sh
or /sbin/sh. I would likely agree with you that this is a bad and
arbitrary decision.
> Is there any way a installation script other than one written in sh be used
> when developing packages?
If you use perl instead, you can put the following (from perlrun(1))
at the very top of your script:
#!/usr/bin/perl
eval 'exec /usr/bin/perl -wS $0 ${1+"$@"}'
if $running_under_some_shell;
There may be similar tricks you could do with bash, but unless it is
being deployed into only a well-known environment (one that you manage
and specify OS contents), I would stay away from bash.
That being said, in the past when I have needed to manage Solaris,
HP-UX, and Linux, I found bash to be the right balance of features and
compatibility. sh on Solaris had shortcomings like you describe, ksh
on Linux was really pdksh and failed in strange ways. If I had bash
on all three platforms I could write a script that always worked the
same.
There is an OpenSolaris effort underway to change from ancient bourne
shell and ksh88 to ksh93 as the default shell. This will be a huge
improvement and address the problems you speak of at some time in the
future.
Mike
--
Mike Gerdts
http://mgerdts.blogspot.com/
