On 8/7/07, James Carlson <james.d.carlson at sun.com> wrote: > It seems a shame to me, though, that the underlying issue in this case > appears to be trivial. Who cares whether install scripts are written > using rotten old Bourne shell or some fancy new shell? As an > architectural matter, these scripts should be doing as little as > possible -- nothing at all if that can be achieved, so that packages > just lay bits on the disk -- and thus going out of our way to provide > fancy scripting support here seems a bit on the pointless side.
I'm not saying that Solaris is wrong or that you are wrong from a purely technical standpoint - it is a matter of making it easier for new developers to provide packaged software for Solaris. People that come from other platforms where /bin/sh implements a fair amount beyond what POSIX says will have troubles with the Solaris Bourne shell. When I've needed to write scripts that are portable across the greatest number of systems, I've either used Bourne shell on Solaris or bash (or Perl) on any platform. /bin/sh on Linux has traditionally looked a lot like bash and /bin/sh on HP-UX has traditionally looked at lot like ksh88. pdksh on Linux was just broken in strange and frustratingly unexpected ways. This was a hard lesson to learn because I came to Solaris from other platforms. What happens when ksh93 is integrated? Does /bin/sh become ksh93? It seems as though this would open the door for people to develop packaging scripts on Solaris.next that don't run on Solaris.previous. (Hmmmm... another question for arc-discuss, likely.) Just out of curiosity, does anyone know why the packaging scripts ignore the sha-bang line? I understand they are explicitly called with /bin/sh or /sbin/sh, but why was that decision made? Is this a lesson that shouldn't be unlearned? Mike -- Mike Gerdts http://mgerdts.blogspot.com/
