Subject: Re: SunOS.mk default shell for SH
To: Eric Boutilier <Eric.Boutilier@Sun.COM>
From: grant beattie <grant@NetBSD.org>
Date: 03/04/2005 08:12:50
Content-Type: text/plain; charset=us-ascii
On Thu, Mar 03, 2005 at 01:06:27PM -0600, Eric Boutilier wrote:
> First, I'm happy to report that in the window manager category
> pkgsrc can cleanly build fvwm2, windowmaker, and fluxbox on my
> Solaris 10 PC -- completely hands-free. (Such "news" is probably
> a yawner to most people here, but I for one still find all this
> quite remarkable!)
> I did have to make one tiny "update" to SunOS.mk to get fluxbox
> to build. Otherwise, it dumps a /bin/ksh core part way through
> the build (right after compiling ToolFactory.o).
> I figured out the work-around is to change SH?=3D /bin/ksh to=20
> SH?=3D /bin/bash in SunOS.mk. Then, instead of changing it back,
> I left it that way with no problems so far.
hmm, that is strange. I wonder what is triggering this and making ksh
side: perhaps a simpler alternative to modifying SunOS.mk is to simply
override the value of SH in mk.conf.
> I looked at the other platform mk files and using /bin/ksh is the
> exception -- most seem to be using /bin/sh -- which is probably
> bash on BSD and Linux systems, and maybe some UNIX systems too.
this was changed to ksh some time ago because the demand for ksh by
some GNU configure scripts was overwhelming.
> Can we do the same for bash? I guess it would look like this:
> .if exists(/bin/bash)
> SH?=3D /bin/bash
> SH?=3D /bin/ksh
perhaps we can override this on a per-pkg basis. I haven't come across
too many packages which have this problem, and while I don't have
numbers, I suspect bash incurs quite an overhead compared to ksh. on
the other hand, if the difference is not significant, then this might
I should read up on the deficiencies of bash compared to ksh, as I
know historically bash has had some ... interesting .. semantics.
> Finally, I have a protocol question. In the future, for this
> kind of thing, should I do this first (open a discussion here)
> and maybe open a PR later? Or should I just open a PR? Or do both
> in parallel?
opening a PR ensures that the issue won't be forgotten about, and
acts as a central point of reference, so I'm in favour of doing both
if there is discussion to be had.
hope this helps,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)
-----END PGP SIGNATURE-----